Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add download and hrefLang attributes #1116

Merged
merged 1 commit into from
Feb 18, 2014
Merged

Conversation

sophiebits
Copy link
Collaborator

Fixes #1115.

@zpao zpao added this to the 0.9 milestone Feb 18, 2014
@zpao
Copy link
Member

zpao commented Feb 18, 2014

Might as well fit it into 0.9. Have I said lately that we should do a proper pass through DOM attributes again?

@syranide
Copy link
Contributor

@zpao I'm starting to feel like the current system is starting to show its limits, is there a good reason why we simply don't accept all unknown names as attributes, null? (and also follow the DOMPropertyConfig) Most of the attributes are really only allowed for one or two of the tags, perhaps it's time to introduce a tag-specific list of "properties" as well so we can be more fine-grained?

@sophiebits
Copy link
Collaborator Author

@syranide I'm concerned that would result in subtly broken updates for many of the attributes.

@syranide
Copy link
Contributor

@spicyj Definitely true, it was mostly based on the pattern of most of the "properties" being just regular "attributes" with no additional checks. I think the real solution would be to maintain a list per "category of tags", that way an input cannot have rowSpan, etc, etc.

@sophiebits
Copy link
Collaborator Author

Is it a problem if I specify rowSpan on an input?

@syranide
Copy link
Contributor

@spicyj Nope, but once DOMPropertyConfig is injectable I see it becoming quite a mess. Attributes and properties for HTML, SVG, etc could potentially conflict even. It's also possible that properties meant for specific components can start being applied to everything. It's starting to feel rather in-elegant at that point.

I see your point, but it seems kind of weird to me to maintain a huge list of all possible properties for all "technologies", it seems like the current solution was intended for only HTML (and not SVG, etc). As opposed to keeping it to a per-technology per-component basis. Intuitively, done right the size cost of maintaining it per component should be minimal.

Perhaps I'm overthinking it, but it seems really unwieldy.

@sophiebits
Copy link
Collaborator Author

Agree that HTML and SVG attributes should be separate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support HTML5 anchor tag attributes
3 participants