Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Mon, May 4, 2015 at 8:52 PM, Lea Verou l...@verou.me wrote: Sorry for reviving such an old thread (almost 3 years now!) but I recently came across a huge use case for CAS: Semantic data! Namely, Microdata and RDFa. They’re both applied using attributes, which makes them super tedious to add to existing content. I like this idea! You might get additional feedback for this from the SWIG community on the semantic-web list. GRDDL is (was?) a very similar, but much more complex, concept that uses RDF/XML and XSLT (not a very well-liked combination by myself or generally): http://www.w3.org/TR/grddl/ Another application would be many of the applications of ARIA attributes (surely I can't be the only one who's thought ARIA shouldn't be embedded in markup since it's not conveying actual data). In both cases, they're properties annotating/semantically enhancing data, where cycles generally shouldn't occur. That is if cycles are a problem at all. CSS doesn't seem to have any issue when it creates pesudo-elements, I don't forsee too many issues with pesudo-attributes. That is, I don't see any reason this would need to modify the DOM; but could instead expose a data DOM that ARIA and RDFa would use; the same way Web browsers render a visual DOM of sorts containing pesudo-elements. Austin Wright.
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Fri, Oct 5, 2012 at 4:22 AM, Henri Sivonen hsivo...@iki.fi wrote: On Tue, Aug 21, 2012 at 9:17 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Similarly, some of the a11y folks have recently been talking about applying aria-* attributes via CSS, again, because it's just so much more convenient. What's the rationale for this radical change of mind? Back when ARIA was introduced, the a11y wanted to specifically avoid the introduction of reflecting DOM properties for the ARIA attributes in order to force authors to use setAttribute() so that JAWS could retrieve the ARIA data via COM in ARIA-unaware legacy IE. If the a11y folks were so serious about being compatible with IE7 a few years ago, why isn't there now similar concern that applying ARIA by a new mechanism would leave behind IE10 and earlier, which, presumably, currently have the same sort of expected enterprise lifespan as IE7 had when aria was introduced? I have no idea. However, it seems irrelevant for my proposal - as currently specified, CAS desugars into setAttribute calls. ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
This can be implemented in script using mutation observers (provided the parser-inserted elements question shakes out in the right direction, which seems a prerequisite for any robust use of that API), right? -- Glenn Maynard
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Aug 27, 2012, at 2:07 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
I have mixed feelings about this proposal overall, but I think it's a little
weird to use CSS property syntax instead of markup-like attribute syntax to
set attributes. I think this makes the syntax confusingly similar to CSS
even though proposed behavior is quite different. Something like this might
make more sense:
img.placeholder {
src=/images/1x1.gif
alt=
}
In other words, make attribute setting look like attribute syntax.
This is similar to the discussions about monocle-mustache in JS. I
prefer being able to simple re-use the existing CSS parser, but I'm
not completely wedded to it. I'd need some strong opinions from more
relevant parties to switch over, though.
I doubt we would be able to actually reuse the CSS parser, at least at the code
level, at least for WebKit. To give some examples of issues that arise:
- The CSS parser has specific knowledge of all the CSS properties we recognize
and their value syntax.
- It has no provision for catchall recognition of all other property names with
a quoted string value.
- There are some CSS properties that have the same name as meaningful HTML
attributes.
And finally, I'm skeptical whether the convenience here is worth adding a
whole new language to the Web Platform technology stack. It is literally
just convenience / syntactic sugar. I'm not sure that rises to the high bar
needed to add an additional language to the Web Platform.
Yeah, this is the major hurdle for this. My hope is that, by reusing
the CSS parser and restricting all the expensive parts of CSS
(dynamicness, remembering where a value came from, etc.), I can pull
the bar down low enough for this to make it.
I think your assumption is that it's possible to reuse the CSS parser is
incorrect, at least for strong values of reuse.
Regards,
Maciej
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Wed, Aug 22, 2012 at 6:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 21, 2012, at 1:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell bkard...@gmail.com wrote:
On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Correct. If we applied CAS on attribute changes, we'd have... problems.
Because you could do something like:
.foo[x=123]{ x: 234; }
.foo[x=234]{ x: 123; }
?
Precisely. Any way around this problem pulls in a lot more complexity
that I don't think is worthwhile.
I suspect it's actually pretty simple to fix. Ban attribute selectors, and
forbid setting the class or id attributes using this language.
It's not that simple. ^_^ You can set the 'checked' attribute, which
activates the :checked pseudo. You can do various things with form
inputs (setting 'required' or 'pattern', setting 'value', setting
'disabled' or 'readonly'), which activate the various input
pseudoclasses. Looking to the future, the reference and column
combinators also respond to attributes in various ways.
I have mixed feelings about this proposal overall, but I think it's a little
weird to use CSS property syntax instead of markup-like attribute syntax to
set attributes. I think this makes the syntax confusingly similar to CSS even
though proposed behavior is quite different. Something like this might make
more sense:
img.placeholder {
src=/images/1x1.gif
alt=
}
In other words, make attribute setting look like attribute syntax.
This is similar to the discussions about monocle-mustache in JS. I
prefer being able to simple re-use the existing CSS parser, but I'm
not completely wedded to it. I'd need some strong opinions from more
relevant parties to switch over, though.
I also think the proposed semi-dynamic behavior of applying only at DOM
insertion time but otherwise being static is super confusing.
Opinions can differ. I think this captures at least 90% of the
use-cases for it, and it's simple to explain, which should help offset
the minor confusion.
And finally, I'm skeptical whether the convenience here is worth adding a
whole new language to the Web Platform technology stack. It is literally just
convenience / syntactic sugar. I'm not sure that rises to the high bar needed
to add an additional language to the Web Platform.
Yeah, this is the major hurdle for this. My hope is that, by reusing
the CSS parser and restricting all the expensive parts of CSS
(dynamicness, remembering where a value came from, etc.), I can pull
the bar down low enough for this to make it.
It is just sugar, but it's *useful* sugar, as evidenced by the fact
that people keep trying to push content attributes into CSS. With
something like this, we can avoid discussions like can we put aria
things into CSS? entirely, because they'll already be handled.
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 5:48 PM, Dimitri Glazkov dglaz...@google.com wrote:
Can we extend this to custom DOM element registration somehow?
ul.newsli {
identity: x-news-item;
}
or maybe even:
ul.newsli {
identity: url(//example.com/test/news.html#news-item);
}
If that's an attribute on the element, sure!
ul.news li { is: x-news-item; }
^_^
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
Yes, but... One of the problems with the is attribute is that it's
magic: only the parser reacts to it, and changing it does not do
anything. I was hoping for some special notation that clearly made it
not an attribute, so that at least the magic is confined to CAS, and
does not extend to weird attribute behavior.
:DG
On Wed, Aug 22, 2012 at 12:09 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 5:48 PM, Dimitri Glazkov dglaz...@google.com wrote:
Can we extend this to custom DOM element registration somehow?
ul.newsli {
identity: x-news-item;
}
or maybe even:
ul.newsli {
identity: url(//example.com/test/news.html#news-item);
}
If that's an attribute on the element, sure!
ul.news li { is: x-news-item; }
^_^
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On 22.8.2012 1:13, Tab Atkins Jr. wrote:
On Tue, Aug 21, 2012 at 4:07 PM, Glenn Maynard gl...@zewt.org wrote:
FWIW, while I don't find the idea of attaching event listeners this way too
interesting (maybe I could be convinced, but event capturing is already
convenient for most of these examples), being able to say #myform input {
autocomplete: off; autocorrect: off; autocapitalize: off; } or a { rel:
noreferrer; } would be great.
Having it not apply changes dynamically seems weird, since it looks and
feels like CSS. It'd mean these two things--which look intuitively the
same, and behave the same with CSS--would be very different when parentNode
is in the document:
var div = createMyDiv();
parentNode.appendChild(div); // our attributes are applied
div.className = foo; // and we override them
var div = createMyDiv();
div.className = foo; // we set an attribute
parentNode.appendChild(div); // and it gets overwritten
Also, the behavior of the latter is different depending on whether
parentNode is within a document or not, so it's now also dependent on
whether, for example, document.documentElement.appendChild(parentNode)
happens before or after.
Actually, the two should be identical, because CAS is applied as a
mutation observer, rather than synchronously. As long as those
statements appear in the same microtask, they'll have the same
behavior regardless of order (CAS will always get to override them).
~TJ
Which does not correspond to CSS behavior and may be cofusing, any
changes would require something like
var div = createMyDiv();
parentNode.appendChild(div);
setTimeout(function(div) {div.className = 'foo';}, 0, div);
that's weird.
How about this: element is created with all attributes marked as clean,
any settings (input.value = 5; input.setAttribute('value', 5); delete
input.value; input.removeAttribute('value')) would mark such property as
dirty, and inserting new element into DOM would trigger task, that would
set up all properties based on DOM document's CAS except dirty ones. In
such case, no ambiguity would occure.
Browsers are able to do it for CSS, should be able to do it for CAS
Brona.
--
s pozdravem
Bronislav Klučka
http://www.bauglir.com http://www.bauglir.com
http://www.bauglir.com
bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com
* webové aplikace
* software na zakázku
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Wed, Aug 22, 2012 at 9:11 AM, Dimitri Glazkov dglaz...@google.com wrote: Yes, but... One of the problems with the is attribute is that it's magic: only the parser reacts to it, and changing it does not do anything. I was hoping for some special notation that clearly made it not an attribute, so that at least the magic is confined to CAS, and does not extend to weird attribute behavior. If it's getting applied by CAS, it does so in a microtask after it was added to the DOM. If anything *can* influence the identity of the element at that point, it might as well be an attribute - making it special doesn't gain us anything. (Anyway, could we move this discussion to a separate thread? It's more about how do we trigger custom elements than about CAS.) ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Wed, Aug 22, 2012 at 9:20 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
On 22.8.2012 1:13, Tab Atkins Jr. wrote:
Actually, the two should be identical, because CAS is applied as a
mutation observer, rather than synchronously. As long as those
statements appear in the same microtask, they'll have the same
behavior regardless of order (CAS will always get to override them).
Which does not correspond to CSS behavior and may be cofusing, any changes
would require something like
var div = createMyDiv();
parentNode.appendChild(div);
setTimeout(function(div) {div.className = 'foo';}, 0, div);
that's weird.
Why do you think that's required? All it would do is clobber the
class attribute in case CAS had set it to something else. Setting a
class via CAS doesn't seem like a great idea in the first place. If
you really do want to, you can just get CAS to either not clobber the
attribute (if I address the add to the existing value use-case that
I've outlined on my blog http://www.xanthir.com/blog/b4K_0) or else
just exclude .foo elements from getting their class clobbered with a
:not(.foo) in the selector.
How about this: element is created with all attributes marked as clean, any
settings (input.value = 5; input.setAttribute('value', 5); delete
input.value; input.removeAttribute('value')) would mark such property as
dirty, and inserting new element into DOM would trigger task, that would set
up all properties based on DOM document's CAS except dirty ones. In such
case, no ambiguity would occure.
Browsers are able to do it for CSS, should be able to do it for CAS
Browsers are able to do it for CSS with a lot of complexity.
Complexity sometimes translates to powerful and awesome, but always
translates to slower. In this case, I don't think the large helping
of additional complexity is worth the minor benefit.
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Aug 21, 2012, at 1:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell bkard...@gmail.com wrote:
On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Correct. If we applied CAS on attribute changes, we'd have... problems.
Because you could do something like:
.foo[x=123]{ x: 234; }
.foo[x=234]{ x: 123; }
?
Precisely. Any way around this problem pulls in a lot more complexity
that I don't think is worthwhile.
I suspect it's actually pretty simple to fix. Ban attribute selectors, and
forbid setting the class or id attributes using this language.
I have mixed feelings about this proposal overall, but I think it's a little
weird to use CSS property syntax instead of markup-like attribute syntax to set
attributes. I think this makes the syntax confusingly similar to CSS even
though proposed behavior is quite different. Something like this might make
more sense:
img.placeholder {
src=/images/1x1.gif
alt=
}
In other words, make attribute setting look like attribute syntax.
I also think the proposed semi-dynamic behavior of applying only at DOM
insertion time but otherwise being static is super confusing.
And finally, I'm skeptical whether the convenience here is worth adding a whole
new language to the Web Platform technology stack. It is literally just
convenience / syntactic sugar. I'm not sure that rises to the high bar needed
to add an additional language to the Web Platform.
Regards,
Maciej
Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
I recently participated in an internal thread at Google where it was
proposed to move a (webkit-specific) feature from an attribute to a
CSS property, because applying it via a property is *much* more
convenient.
Similarly, some of the a11y folks have recently been talking about
applying aria-* attributes via CSS, again, because it's just so much
more convenient.
I think there are probably a lot of examples of this, where something
definitely belongs in an attribute, but it would just be so *nice* to
set it with something like CSS, where you declare it once and
everything just works. For example, inline event handlers!
Given all this, I have a proposal for a method of doing that. It's
very similar to CSS and gives most of the benefits, but should avoid
some pitfalls that have sunk similar proposals in the past.
Cascading Attribute Sheets
===
CAS is a language using the same basic syntax of CSS, meant for easily
applying attributes to an HTML page.
To use it, include a CAS file using script type=text/cas. (I
chose script over style, even though it resembles CSS, because it
acts more like a script - it's run once, no dynamic mutations to the
file, etc.) CAS scripts are automatically async.
The basic grammar of CAS is identical to CSS. Your attribute sheet
contains rules, composed of selectors, curly braces, and declarations,
like so:
video {
preload: metadata;
}
#content video {
preload: auto;
}
In the place where CSS normally has a property name, CAS allows any
attribute name. In the value, CAS allows any single token, such as a
number, identifier, or string. If the value is a string, it's used as
the attribute's value. Otherwise, the value is serialized using CSS
serialization rules, and that is used as the attribute's value.
There are three special values you may use instead to set the value:
!on sets an attribute to its name (shorthand for boolean attributes),
!off removes an attribute (boolean or not), and !initial does nothing
(it's used to cancel any changes that other, less specific, rules may
be attempting to make, and is the initial value of all properties).
CAS files are *not* as dynamic as CSS. They do not respond to
arbitrary document changes. (They *can't*, otherwise you have
dependency cycles with an attribute selector rule removing the
attribute, etc.) My thought right now is that your CAS is only
applied to elements when they are inserted into the DOM (this also
applies to any parser-created elements in the page). This allows us
to keep information tracking to a bare minimum - we don't need to
track what attributes came from CAS vs the markup or setAttribute()
calls, we don't need to define precedence between CAS and other
sources, and we don't need to do any of the fancy coalescing and
whatnot that CSS changes require. Semantically, a CAS file should be
exactly equivalent to a script that does
document.querySelectorAll(selector).forEach(do attribute
mutations);, plus a mutation observer that reruns the mutations on
any nodes added to the document. It's just a much more convenient way
to express these.
(Slight weirdness here - a CAS file can reset its own @src attribute
to load *another* CAS file. A script can do the same, though.
Acceptable or not?)
I think we should allow the CSS Conditional rules as well
http://dev.w3.org/csswg/css3-conditional/ - at least Media Queries,
but @document seems useful as well, and @supports may even by
justifiable (it would need some definition work to make it usable for
CAS, though). Again, these aren't responsive to live changes, like MQ
are in CSS, but they let you respond to the initial document condition
and apply attributes accordingly.
Thoughts? I tried to make this as simple as possible while still
being useful, so that it's easy to implement and to understand.
Hopefully I succeeded!
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 11:17 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
I recently participated in an internal thread at Google where it was
proposed to move a (webkit-specific) feature from an attribute to a
CSS property, because applying it via a property is *much* more
convenient.
Similarly, some of the a11y folks have recently been talking about
applying aria-* attributes via CSS, again, because it's just so much
more convenient.
I think there are probably a lot of examples of this, where something
definitely belongs in an attribute, but it would just be so *nice* to
set it with something like CSS, where you declare it once and
everything just works. For example, inline event handlers!
Given all this, I have a proposal for a method of doing that. It's
very similar to CSS and gives most of the benefits, but should avoid
some pitfalls that have sunk similar proposals in the past.
Cascading Attribute Sheets
===
CAS is a language using the same basic syntax of CSS, meant for easily
applying attributes to an HTML page.
To use it, include a CAS file using script type=text/cas. (I
chose script over style, even though it resembles CSS, because it
acts more like a script - it's run once, no dynamic mutations to the
file, etc.) CAS scripts are automatically async.
The basic grammar of CAS is identical to CSS. Your attribute sheet
contains rules, composed of selectors, curly braces, and declarations,
like so:
video {
preload: metadata;
}
#content video {
preload: auto;
}
In the place where CSS normally has a property name, CAS allows any
attribute name. In the value, CAS allows any single token, such as a
number, identifier, or string. If the value is a string, it's used as
the attribute's value. Otherwise, the value is serialized using CSS
serialization rules, and that is used as the attribute's value.
There are three special values you may use instead to set the value:
!on sets an attribute to its name (shorthand for boolean attributes),
!off removes an attribute (boolean or not), and !initial does nothing
(it's used to cancel any changes that other, less specific, rules may
be attempting to make, and is the initial value of all properties).
CAS files are *not* as dynamic as CSS. They do not respond to
arbitrary document changes. (They *can't*, otherwise you have
dependency cycles with an attribute selector rule removing the
attribute, etc.) My thought right now is that your CAS is only
applied to elements when they are inserted into the DOM (this also
applies to any parser-created elements in the page). This allows us
to keep information tracking to a bare minimum - we don't need to
track what attributes came from CAS vs the markup or setAttribute()
calls, we don't need to define precedence between CAS and other
sources, and we don't need to do any of the fancy coalescing and
whatnot that CSS changes require. Semantically, a CAS file should be
exactly equivalent to a script that does
document.querySelectorAll(selector).forEach(do attribute
mutations);, plus a mutation observer that reruns the mutations on
any nodes added to the document. It's just a much more convenient way
to express these.
Meh. I think this loses most of the CSS is so much more convenient
benefits. It's mainly the fact that you don't have to worry about whether
the nodes exist yet that makes CSS more convenient.
That said, I share your worry that having this be dynamic would slow down
DOM modification too much.
What if we only allowed a restricted set of selectors and made these sheets
dynamic instead? Simple, non-pseudo selectors have information that is all
local to the node itself (e.g. can be applied before the node is in the
DOM). Maybe even just restrict it to IDs and classes. I think that would
meet the majority use-case much better.
Alternately, what if these applied the attributes asynchronously (e.g.
right before style resolution)?
(Slight weirdness here - a CAS file can reset its own @src attribute
to load *another* CAS file. A script can do the same, though.
Acceptable or not?)
I think we should allow the CSS Conditional rules as well
http://dev.w3.org/csswg/css3-conditional/ - at least Media Queries,
but @document seems useful as well, and @supports may even by
justifiable (it would need some definition work to make it usable for
CAS, though). Again, these aren't responsive to live changes, like MQ
are in CSS, but they let you respond to the initial document condition
and apply attributes accordingly.
Thoughts? I tried to make this as simple as possible while still
being useful, so that it's easy to implement and to understand.
Hopefully I succeeded!
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote: Meh. I think this loses most of the CSS is so much more convenient benefits. It's mainly the fact that you don't have to worry about whether the nodes exist yet that makes CSS more convenient. Note that this benefit is preserved. Moving or inserting an element in the DOM should apply CAS to it. The only thing we're really losing in the dynamic-ness is that other types of mutations to the DOM don't change what CAS does, and some of the dynamic selectors like :hover don't do anything. That said, I share your worry that having this be dynamic would slow down DOM modification too much. What if we only allowed a restricted set of selectors and made these sheets dynamic instead? Simple, non-pseudo selectors have information that is all local to the node itself (e.g. can be applied before the node is in the DOM). Maybe even just restrict it to IDs and classes. I think that would meet the majority use-case much better. I think that being able to use complex selectors is a sufficiently large use-case that we should keep it. Alternately, what if these applied the attributes asynchronously (e.g. right before style resolution)? Can you elaborate? ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Aug 21, 2012 4:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote: Meh. I think this loses most of the CSS is so much more convenient benefits. It's mainly the fact that you don't have to worry about whether the nodes exist yet that makes CSS more convenient. Note that this benefit is preserved. Moving or inserting an element in the DOM should apply CAS to it. The only thing we're really losing in the dynamic-ness is that other types of mutations to the DOM don't change what CAS does, and some of the dynamic selectors like :hover don't do anything. So if I had a selector .foo .bar and then some script inserted a .bar inside a .foo - that would work... but if I added a .bar class to some existing child of .foo it would not...is that right? That said, I share your worry that having this be dynamic would slow down DOM modification too much. What if we only allowed a restricted set of selectors and made these sheets dynamic instead? Simple, non-pseudo selectors have information that is all local to the node itself (e.g. can be applied before the node is in the DOM). Maybe even just restrict it to IDs and classes. I think that would meet the majority use-case much better. I think that being able to use complex selectors is a sufficiently large use-case that we should keep it. Alternately, what if these applied the attributes asynchronously (e.g. right before style resolution)? Can you elaborate? ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 1:30 PM, Brian Kardell bkard...@gmail.com wrote: On Aug 21, 2012 4:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote: Meh. I think this loses most of the CSS is so much more convenient benefits. It's mainly the fact that you don't have to worry about whether the nodes exist yet that makes CSS more convenient. Note that this benefit is preserved. Moving or inserting an element in the DOM should apply CAS to it. The only thing we're really losing in the dynamic-ness is that other types of mutations to the DOM don't change what CAS does, and some of the dynamic selectors like :hover don't do anything. So if I had a selector .foo .bar and then some script inserted a .bar inside a .foo - that would work... but if I added a .bar class to some existing child of .foo it would not...is that right? Correct. If we applied CAS on attribute changes, we'd have... problems. ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 1:30 PM, Brian Kardell bkard...@gmail.com wrote:
On Aug 21, 2012 4:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote:
Meh. I think this loses most of the CSS is so much more convenient
benefits. It's mainly the fact that you don't have to worry about
whether
the nodes exist yet that makes CSS more convenient.
Note that this benefit is preserved. Moving or inserting an element
in the DOM should apply CAS to it.
The only thing we're really losing in the dynamic-ness is that other
types of mutations to the DOM don't change what CAS does, and some of
the dynamic selectors like :hover don't do anything.
So if I had a selector .foo .bar and then some script inserted a .bar inside
a .foo - that would work... but if I added a .bar class to some existing
child of .foo it would not...is that right?
Correct. If we applied CAS on attribute changes, we'd have... problems.
~TJ
Because you could do something like:
.foo[x=123]{ x: 234; }
.foo[x=234]{ x: 123; }
?
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote: Meh. I think this loses most of the CSS is so much more convenient benefits. It's mainly the fact that you don't have to worry about whether the nodes exist yet that makes CSS more convenient. Note that this benefit is preserved. Moving or inserting an element in the DOM should apply CAS to it. The only thing we're really losing in the dynamic-ness is that other types of mutations to the DOM don't change what CAS does, and some of the dynamic selectors like :hover don't do anything. Ah, I missed the plus a mutation observer that reruns the mutations on any nodes added to the document bit. Ok, so this timing is very specific then. It would get applied at the microtask time, not at the time the DOM was modified. Would it get applied before or after mutation observers get called? Seems like you'd want it to execute first. Calling it after mutation observers would require an extra delivery of mutations after the attributes are applied, which seems silly. That said, I share your worry that having this be dynamic would slow down DOM modification too much. What if we only allowed a restricted set of selectors and made these sheets dynamic instead? Simple, non-pseudo selectors have information that is all local to the node itself (e.g. can be applied before the node is in the DOM). Maybe even just restrict it to IDs and classes. I think that would meet the majority use-case much better. I think that being able to use complex selectors is a sufficiently large use-case that we should keep it. Alternately, what if these applied the attributes asynchronously (e.g. right before style resolution)? Can you elaborate? ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 1:37 PM, Brian Kardell bkard...@gmail.com wrote:
On Tue, Aug 21, 2012 at 4:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Correct. If we applied CAS on attribute changes, we'd have... problems.
Because you could do something like:
.foo[x=123]{ x: 234; }
.foo[x=234]{ x: 123; }
?
Precisely. Any way around this problem pulls in a lot more complexity
that I don't think is worthwhile.
~TJ
RE: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote: Meh. I think this loses most of the CSS is so much more convenient benefits. It's mainly the fact that you don't have to worry about whether the nodes exist yet that makes CSS more convenient. Note that this benefit is preserved. Moving or inserting an element in the DOM should apply CAS to it. The only thing we're really losing in the dynamic-ness is that other types of mutations to the DOM don't change what CAS does, and some of the dynamic selectors like :hover don't do anything. Ah, I missed the plus a mutation observer that reruns the mutations on any nodes added to the document bit. Ok, so this timing is very specific then. It would get applied at the microtask time, not at the time the DOM was modified. Would it get applied before or after mutation observers get called? Seems like you'd want it to execute first. Calling it after mutation observers would require an extra delivery of mutations after the attributes are applied, which seems silly. I presume there's an ordering of mutation observers, such that ones defined earlier in document history get the notifications first, or somesuch? If so, CAS should indeed run before any author-defined observers. So this can basically be completely authored as a script library using existing or soon-to-be-implemented technologies? You just need a CAS JS parser, CAS JS rule engine, and mutation observers? Tab, you should just supply an implementation of this. :)
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 2:20 PM, Travis Leithead travis.leith...@microsoft.com wrote: From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote: Meh. I think this loses most of the CSS is so much more convenient benefits. It's mainly the fact that you don't have to worry about whether the nodes exist yet that makes CSS more convenient. Note that this benefit is preserved. Moving or inserting an element in the DOM should apply CAS to it. The only thing we're really losing in the dynamic-ness is that other types of mutations to the DOM don't change what CAS does, and some of the dynamic selectors like :hover don't do anything. Ah, I missed the plus a mutation observer that reruns the mutations on any nodes added to the document bit. Ok, so this timing is very specific then. It would get applied at the microtask time, not at the time the DOM was modified. Would it get applied before or after mutation observers get called? Seems like you'd want it to execute first. Calling it after mutation observers would require an extra delivery of mutations after the attributes are applied, which seems silly. I presume there's an ordering of mutation observers, such that ones defined earlier in document history get the notifications first, or somesuch? If so, CAS should indeed run before any author-defined observers. So this can basically be completely authored as a script library using existing or soon-to-be-implemented technologies? You just need a CAS JS parser, CAS JS rule engine, and mutation observers? Tab, you should just supply an implementation of this. :) I could, yes. ^_^ However, you can just do it as a library isn't an argument against adding a feature to the platform, if the feature is sufficiently useful. ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 1:58 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Aug 21, 2012 at 1:42 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Aug 21, 2012 at 1:01 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 12:37 PM, Ojan Vafai o...@chromium.org wrote: Meh. I think this loses most of the CSS is so much more convenient benefits. It's mainly the fact that you don't have to worry about whether the nodes exist yet that makes CSS more convenient. Note that this benefit is preserved. Moving or inserting an element in the DOM should apply CAS to it. The only thing we're really losing in the dynamic-ness is that other types of mutations to the DOM don't change what CAS does, and some of the dynamic selectors like :hover don't do anything. Ah, I missed the plus a mutation observer that reruns the mutations on any nodes added to the document bit. Ok, so this timing is very specific then. It would get applied at the microtask time, not at the time the DOM was modified. Would it get applied before or after mutation observers get called? Seems like you'd want it to execute first. Calling it after mutation observers would require an extra delivery of mutations after the attributes are applied, which seems silly. I presume there's an ordering of mutation observers, such that ones defined earlier in document history get the notifications first, or somesuch? Correct. If so, CAS should indeed run before any author-defined observers. On a somewhat unrelated note, could we somehow also incorporate jquery style live event handlers here? See previous www-dom discussion about this: . I suppose we'd still just want listen/unlisten(selector, handler) methods, but they'd get applied at the same time as cascaded attributes. Although, we might want to apply those on attribute changes as well.
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Aug 21, 2012 5:40 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai o...@chromium.org wrote: On a somewhat unrelated note, could we somehow also incorporate jquery style live event handlers here? See previous www-dom discussion about this: . I suppose we'd still just want listen/unlisten(selector, handler) methods, but they'd get applied at the same time as cascaded attributes. Although, we might want to apply those on attribute changes as well. Using CAS to apply an onfoo attribute is nearly the same (use a string value to pass the function, obviously). It'll only allow a single listener to be applied, though. If it's considered worthwhile, we can magic up this case a bit. CAS properties don't accept functions normally (or rather, as I have it defined in the OP, it would just accept a FUNCTION token, which is just the function name and opening paren, but I should tighten up that definition). We could have a magic function like listen(string) that, when used on an onfoo attribute (more generally, on a host-language-defined event listener attribute) does an addEventListener() call rather than a setAttribute() call. ~TJ Can you give some pseudo code or something that is relatively close to what you mean here? I'm not entirely sure I follow.
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 3:15 PM, Brian Kardell bkard...@gmail.com wrote:
On Aug 21, 2012 5:40 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai o...@chromium.org wrote:
On a somewhat unrelated note, could we somehow also incorporate jquery
style
live event handlers here? See previous www-dom discussion about this: .
I
suppose we'd still just want listen/unlisten(selector, handler) methods,
but
they'd get applied at the same time as cascaded attributes. Although, we
might want to apply those on attribute changes as well.
Using CAS to apply an onfoo attribute is nearly the same (use a
string value to pass the function, obviously). It'll only allow a
single listener to be applied, though.
If it's considered worthwhile, we can magic up this case a bit. CAS
properties don't accept functions normally (or rather, as I have it
defined in the OP, it would just accept a FUNCTION token, which is
just the function name and opening paren, but I should tighten up that
definition). We could have a magic function like listen(string)
that, when used on an onfoo attribute (more generally, on a
host-language-defined event listener attribute) does an
addEventListener() call rather than a setAttribute() call.
Can you give some pseudo code or something that is relatively close to what
you mean here? I'm not entirely sure I follow.
Sure!
So, in my current proposal, you can just set an onfoo attribute:
ul.special li {
onclick: alert('You clicked me!'); evt.target.classlist.add('clicked');;
}
Here's a suggestion for a similar API that would invoke
addEventListener instead of setAttribute:
ul.special li {
onclick: listen(alert('You clicked me!');
evt.target.classlist.add('clicked'););
}
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
Comments inline...
On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Aug 21, 2012 at 3:15 PM, Brian Kardell bkard...@gmail.com wrote:
On Aug 21, 2012 5:40 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai o...@chromium.org wrote:
On a somewhat unrelated note, could we somehow also incorporate jquery
style
live event handlers here? See previous www-dom discussion about this: .
I
suppose we'd still just want listen/unlisten(selector, handler)
methods,
but
they'd get applied at the same time as cascaded attributes. Although,
we
might want to apply those on attribute changes as well.
Using CAS to apply an onfoo attribute is nearly the same (use a
string value to pass the function, obviously). It'll only allow a
single listener to be applied, though.
If it's considered worthwhile, we can magic up this case a bit. CAS
properties don't accept functions normally (or rather, as I have it
defined in the OP, it would just accept a FUNCTION token, which is
just the function name and opening paren, but I should tighten up that
definition). We could have a magic function like listen(string)
that, when used on an onfoo attribute (more generally, on a
host-language-defined event listener attribute) does an
addEventListener() call rather than a setAttribute() call.
Can you give some pseudo code or something that is relatively close to
what
you mean here? I'm not entirely sure I follow.
Sure!
So, in my current proposal, you can just set an onfoo attribute:
ul.special li {
onclick: alert('You clicked me!');
evt.target.classlist.add('clicked');;
}
This is certainly interesting, but...
1. It's a string that will have to be eval'ed, right? In what scope? Does
this get wrapped in a function expression?
2. Using inline attributes that match up to node.onfoo will pave over each
other... if some other style sheet is introduced, by some third party
widget that happens to have
ul.special li {
onclick: alert('busted');
}
...Bummer?
3. Where did evt come from?
Here's a suggestion for a similar API that would invoke
addEventListener instead of setAttribute:
ul.special li {
onclick: listen(alert('You clicked me!');
evt.target.classlist.add('clicked'););
}
How do we know where the body ends?
~TJ
Thanks in advance! :)
Rick
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 3:29 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
ul.special li {
onclick: alert('You clicked me!');
evt.target.classlist.add('clicked');;
}
This is certainly interesting, but...
1. It's a string that will have to be eval'ed, right? In what scope? Does
this get wrapped in a function expression?
No, it's a string that gets passed as an argument to setAttribute()
(or the moral equivalent of such). Any eval'ing that happens is just
part of the normal way that onfoo attributes are handled.
2. Using inline attributes that match up to node.onfoo will pave over each
other... if some other style sheet is introduced, by some third party widget
that happens to have
ul.special li {
onclick: alert('busted');
}
...Bummer?
Yes. That's why I just suggested the listen() function, which would
invoke addEventListener instead of setAttribute.
This *would* require a little bit more detail about evaling the
string. I suppose it should just be passed through the Function
constructor in the global scope before being passed to aEL.
3. Where did evt come from?
Isn't that one of the magically-defined variables in inline event
handlers? If not, swap it out with whatever the correct equivalent
is.
Here's a suggestion for a similar API that would invoke
addEventListener instead of setAttribute:
ul.special li {
onclick: listen(alert('You clicked me!');
evt.target.classlist.add('clicked'););
}
How do we know where the body ends?
Do you mean the function body? It's a string. The end is well-defined. ^_^
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
I *love* this idea!! However, I’m afraid that in all these cases, ”it’s so much more convenient” precisely due to the dynamic nature of CSS, so you don’t have to bind event handlers to cater to document changes etc. I think this proposal would be much more useful if it was dynamic in at least *some* ways. I'm probably missing something here, but there are many algorithms to prevent cycle detection. There are even other technologies in the open web stack which could result to circular relationships. For example, let me quote CSS Image Values 4 [1]: The ‘element()’ function can produce nonsensical circular relationships, such as an element using itself as its own background. These relationships can be easily and reliably detected and resolved, however, by keeping track of a dependency graph and using common cycle-detection algorithms. Dropping dynamicity altogether because of a few edge cases doesn't sound like a good idea. Why not just disallow these cases from triggering it? For example, maybe we could define CAS not to be dynamic for changes made through CAS? What other cycles are there? If such a thing is not possible or too slow, I think restricting the set of allowed selectors like Ojan suggested, would be a more acceptable tradeoff than making the whole thing static. [1]: http://dev.w3.org/csswg/css4-images/#element-cycles Lea Verou W3C developer relations http://w3.org/people/all#lea ✿ http://lea.verou.me ✿ @leaverou On Aug 21, 2012, at 11:17, Tab Atkins Jr. wrote: I recently participated in an internal thread at Google where it was proposed to move a (webkit-specific) feature from an attribute to a CSS property, because applying it via a property is *much* more convenient. [snip] Thoughts? I tried to make this as simple as possible while still being useful, so that it's easy to implement and to understand. Hopefully I succeeded! ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 6:40 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Aug 21, 2012 at 3:29 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
ul.special li {
onclick: alert('You clicked me!');
evt.target.classlist.add('clicked');;
}
This is certainly interesting, but...
1. It's a string that will have to be eval'ed, right? In what scope? Does
this get wrapped in a function expression?
No, it's a string that gets passed as an argument to setAttribute()
(or the moral equivalent of such). Any eval'ing that happens is just
part of the normal way that onfoo attributes are handled.
Ah-ha, I was thinking of this a bit too script literally
2. Using inline attributes that match up to node.onfoo will pave over
each
other... if some other style sheet is introduced, by some third party
widget
that happens to have
ul.special li {
onclick: alert('busted');
}
...Bummer?
Yes. That's why I just suggested the listen() function, which would
invoke addEventListener instead of setAttribute.
This *would* require a little bit more detail about evaling the
string. I suppose it should just be passed through the Function
constructor in the global scope before being passed to aEL.
3. Where did evt come from?
Isn't that one of the magically-defined variables in inline event
handlers? If not, swap it out with whatever the correct equivalent
is.
Nope? (Maybe in 1990's? :D )
Here's a suggestion for a similar API that would invoke
addEventListener instead of setAttribute:
ul.special li {
onclick: listen(alert('You clicked me!');
evt.target.classlist.add('clicked'););
}
How do we know where the body ends?
Do you mean the function body? It's a string. The end is well-defined.
^_^
Yep, function body.
The string broke over two lines and tricked my eyes and brain. ;)
Rick
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Aug 21, 2012 6:49 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 3:44 PM, Brian Kardell bkard...@gmail.com wrote:
On Aug 21, 2012 6:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
So, in my current proposal, you can just set an onfoo attribute:
ul.special li {
onclick: alert('You clicked me!');
evt.target.classlist.add('clicked');;
}
Here's a suggestion for a similar API that would invoke
addEventListener instead of setAttribute:
ul.special li {
onclick: listen(alert('You clicked me!');
evt.target.classlist.add('clicked'););
}
This feels a lot like netscape's old actionsheets proposal. Doesn't it
create the same footgun I mentioned above though? Would you be blocked
off
from accessing dom in those handlers? Or are the read only (you may
remember
you, borris and I discussed how that might work last year) In other
words,
what is preventing you from writing...
.foo .bar{
onclick: listen(create a .bar and attach it as a child of
evt.target);
}
Nothing prevents you from writing that. That's not problematic at
all, though. When you click on a .bar, it creates a sibling .bar and
gives it the same onclick. I think you've confused yourself into
thinking this is an infinite loop - it's not.
Since you can't create a mutation observer with an attribute, I don't
think you can infinite-loop yourself at all. Even if you could, it's
no more troublesome than the same possibility in pure JS.
~TJ
You are right, I was thinking that :) I blame it on doing this all on my
cell phone. Ok. If you click on the inner foo, now both will fire unless
you pop the bubble, right? That is probably fine. Do you need the quotes
if you do it inside a type fn like listen? Could we not parse around
that?
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 3:51 PM, Lea Verou l...@w3.org wrote: I *love* this idea!! However, I’m afraid that in all these cases, ”it’s so much more convenient” precisely due to the dynamic nature of CSS, so you don’t have to bind event handlers to cater to document changes etc. I think this proposal would be much more useful if it was dynamic in at least *some* ways. I'm probably missing something here, but there are many algorithms to prevent cycle detection. There are even other technologies in the open web stack which could result to circular relationships. For example, let me quote CSS Image Values 4 [1]: The ‘element()’ function can produce nonsensical circular relationships, such as an element using itself as its own background. These relationships can be easily and reliably detected and resolved, however, by keeping track of a dependency graph and using common cycle-detection algorithms. Dropping dynamicity altogether because of a few edge cases doesn't sound like a good idea. Why not just disallow these cases from triggering it? For example, maybe we could define CAS not to be dynamic for changes made through CAS? What other cycles are there? If such a thing is not possible or too slow, I think restricting the set of allowed selectors like Ojan suggested, would be a more acceptable tradeoff than making the whole thing static. The biggest problem with making this more dynamic is that it means you have to carry around *two* versions of each attribute - the native value and the CAS-applied value, so that you can undo the CAS when the selector no longer matches. This makes all attribute changes slower, and all DOM nodes roughly twice as large (or just more complex, if they generate the CAS version only when necessary). It also means we need to define which version wins. It's less than obvious what the correct answer should be if, later in the document's life, a script does an explicit setAttribute(). Is this changing the native value (and thus is ignored if CAS is already setting that attribute)? Or is it setting the attribute in a higher-specificity way, similar to setting el.style versus normal CSS? No matter which one you choose, you might be wrong! It's just a lot of complication for very little benefit, I think. The vast majority of cases should be okay with just setting attributes when an element arrives in the DOM. ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 3:52 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Aug 21, 2012 at 6:40 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Aug 21, 2012 at 3:29 PM, Rick Waldron waldron.r...@gmail.com 3. Where did evt come from? Isn't that one of the magically-defined variables in inline event handlers? If not, swap it out with whatever the correct equivalent is. Nope? (Maybe in 1990's? :D ) Ah, right, it's an old SVG-ism. However, event is automatically defined in inline event handlers. ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 3:54 PM, Brian Kardell bkard...@gmail.com wrote:
On Aug 21, 2012 6:49 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 3:44 PM, Brian Kardell bkard...@gmail.com wrote:
In other
words,
what is preventing you from writing...
.foo .bar{
onclick: listen(create a .bar and attach it as a child of
evt.target);
}
Nothing prevents you from writing that. That's not problematic at
all, though. When you click on a .bar, it creates a sibling .bar and
gives it the same onclick. I think you've confused yourself into
thinking this is an infinite loop - it's not.
Since you can't create a mutation observer with an attribute, I don't
think you can infinite-loop yourself at all. Even if you could, it's
no more troublesome than the same possibility in pure JS.
You are right, I was thinking that :) I blame it on doing this all on my
cell phone. Ok. If you click on the inner foo, now both will fire unless
you pop the bubble, right? That is probably fine.
Sure. That's exactly what you wrote, so that's what we do.
Do you need the quotes
if you do it inside a type fn like listen? Could we not parse around that?
I'd prefer not trying to do that. Wouldn't we have to do JS parsing
in there? String is easy, because you can just use CSS rules.
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
FWIW, while I don't find the idea of attaching event listeners this way too
interesting (maybe I could be convinced, but event capturing is already
convenient for most of these examples), being able to say #myform input {
autocomplete: off; autocorrect: off; autocapitalize: off; } or a { rel:
noreferrer; } would be great.
Having it not apply changes dynamically seems weird, since it looks and
feels like CSS. It'd mean these two things--which look intuitively the
same, and behave the same with CSS--would be very different when parentNode
is in the document:
var div = createMyDiv();
parentNode.appendChild(div); // our attributes are applied
div.className = foo; // and we override them
var div = createMyDiv();
div.className = foo; // we set an attribute
parentNode.appendChild(div); // and it gets overwritten
Also, the behavior of the latter is different depending on whether
parentNode is within a document or not, so it's now also dependent on
whether, for example, document.documentElement.appendChild(parentNode)
happens before or after.
--
Glenn Maynard
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
Ah, right, mea culpa. There’s still the option of restricting attribute selectors altogether or just not responding to attribute changes, but doing so for other kinds of changes. Of course being dynamic in some ways but not others will make it harder to teach and learn, but I believe the tradeoff is worth it. Lea Verou W3C developer relations http://w3.org/people/all#lea ✿ http://lea.verou.me ✿ @leaverou On Aug 21, 2012, at 15:59, Tab Atkins Jr. wrote: On Tue, Aug 21, 2012 at 3:51 PM, Lea Verou l...@w3.org wrote: I *love* this idea!! However, I’m afraid that in all these cases, ”it’s so much more convenient” precisely due to the dynamic nature of CSS, so you don’t have to bind event handlers to cater to document changes etc. I think this proposal would be much more useful if it was dynamic in at least *some* ways. I'm probably missing something here, but there are many algorithms to prevent cycle detection. There are even other technologies in the open web stack which could result to circular relationships. For example, let me quote CSS Image Values 4 [1]: The ‘element()’ function can produce nonsensical circular relationships, such as an element using itself as its own background. These relationships can be easily and reliably detected and resolved, however, by keeping track of a dependency graph and using common cycle-detection algorithms. Dropping dynamicity altogether because of a few edge cases doesn't sound like a good idea. Why not just disallow these cases from triggering it? For example, maybe we could define CAS not to be dynamic for changes made through CAS? What other cycles are there? If such a thing is not possible or too slow, I think restricting the set of allowed selectors like Ojan suggested, would be a more acceptable tradeoff than making the whole thing static. The biggest problem with making this more dynamic is that it means you have to carry around *two* versions of each attribute - the native value and the CAS-applied value, so that you can undo the CAS when the selector no longer matches. This makes all attribute changes slower, and all DOM nodes roughly twice as large (or just more complex, if they generate the CAS version only when necessary). [snip] It's just a lot of complication for very little benefit, I think. The vast majority of cases should be okay with just setting attributes when an element arrives in the DOM. ~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
On Tue, Aug 21, 2012 at 4:07 PM, Glenn Maynard gl...@zewt.org wrote:
FWIW, while I don't find the idea of attaching event listeners this way too
interesting (maybe I could be convinced, but event capturing is already
convenient for most of these examples), being able to say #myform input {
autocomplete: off; autocorrect: off; autocapitalize: off; } or a { rel:
noreferrer; } would be great.
Having it not apply changes dynamically seems weird, since it looks and
feels like CSS. It'd mean these two things--which look intuitively the
same, and behave the same with CSS--would be very different when parentNode
is in the document:
var div = createMyDiv();
parentNode.appendChild(div); // our attributes are applied
div.className = foo; // and we override them
var div = createMyDiv();
div.className = foo; // we set an attribute
parentNode.appendChild(div); // and it gets overwritten
Also, the behavior of the latter is different depending on whether
parentNode is within a document or not, so it's now also dependent on
whether, for example, document.documentElement.appendChild(parentNode)
happens before or after.
Actually, the two should be identical, because CAS is applied as a
mutation observer, rather than synchronously. As long as those
statements appear in the same microtask, they'll have the same
behavior regardless of order (CAS will always get to override them).
~TJ
Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!
Can we extend this to custom DOM element registration somehow?
ul.newsli {
identity: x-news-item;
}
or maybe even:
ul.newsli {
identity: url(//example.com/test/news.html#news-item);
}
:DG
On Tue, Aug 21, 2012 at 4:13 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Aug 21, 2012 at 4:07 PM, Glenn Maynard gl...@zewt.org wrote:
FWIW, while I don't find the idea of attaching event listeners this way too
interesting (maybe I could be convinced, but event capturing is already
convenient for most of these examples), being able to say #myform input {
autocomplete: off; autocorrect: off; autocapitalize: off; } or a { rel:
noreferrer; } would be great.
Having it not apply changes dynamically seems weird, since it looks and
feels like CSS. It'd mean these two things--which look intuitively the
same, and behave the same with CSS--would be very different when parentNode
is in the document:
var div = createMyDiv();
parentNode.appendChild(div); // our attributes are applied
div.className = foo; // and we override them
var div = createMyDiv();
div.className = foo; // we set an attribute
parentNode.appendChild(div); // and it gets overwritten
Also, the behavior of the latter is different depending on whether
parentNode is within a document or not, so it's now also dependent on
whether, for example, document.documentElement.appendChild(parentNode)
happens before or after.
Actually, the two should be identical, because CAS is applied as a
mutation observer, rather than synchronously. As long as those
statements appear in the same microtask, they'll have the same
behavior regardless of order (CAS will always get to override them).
~TJ
