On Wed, May 14, 2014 at 1:18 PM, Soledad Penadés wrote:
> And that's where I suggested leaving attribute handling to the component. If
> it "self-registers" as handling a certain attribute, then don't let the UA
> handle it as it would do if unregistered.
Very much like the idea.
A potential is
On Wed, May 14, 2014 at 7:18 AM, Soledad Penadés wrote:
[snip]
> And that's where I suggested leaving attribute handling to the component.
> If it "self-registers" as handling a certain attribute, then don't let the
> UA handle it as it would do if unregistered.
>
>
I'm not sure what this means
On Tue, May 13, 2014 at 5:44 PM, Boris Zbarsky wrote:
> I slightly worry about the performance implications of this and the number
> of changes to UAs this will require: any place inside a UA that examines
> attribute values (only for global attributes?) would need to consult this
> reservation in
On 13/05/2014 10:37, Anne van Kesteren wrote:
Sole had the idea of providing hooks for attributes so a component can
say it handles them rather than the user agent. That makes a lot of
sense to me. That way you can grab any name, even existing ones.
Thank you for adding this idea to the list,
> On May 13, 2014, at 2:37 AM, Anne van Kesteren wrote:
>
>> On Mon, May 12, 2014 at 9:39 PM, Ryosuke Niwa wrote:
>> But expandos are usually added to HTMLElement and other builtin elements,
>> right?
>
> Depends, might be on instances too.
Sure, authors can do anything they please to do but
On 5/13/14, 7:31 AM, Dimitri Glazkov wrote:
Sole had the idea of providing hooks for attributes so a component can
say it handles them rather than the user agent. That makes a lot of
sense to me. That way you can grab any name, even existing ones.
<3 this idea, would love to hear more. It's lik
On Tue, May 13, 2014 at 2:37 AM, Anne van Kesteren wrote:
> Sole had the idea of providing hooks for attributes so a component can
> say it handles them rather than the user agent. That makes a lot of
> sense to me. That way you can grab any name, even existing ones.
<3 this idea, would love to
On Thu, 08 May 2014 19:42:04 +0200, Ian Hickson wrote:
On Thu, 8 May 2014, Bruce Lawson wrote:
On 7 May 2014 20:03, Ian Hickson wrote:
>
> Requiring a dash is pretty ugly. I would allow any attribute, and
> we'll just have to be careful when introducing new global ones.
I think the ship HMS
On Mon, May 12, 2014 at 9:39 PM, Ryosuke Niwa wrote:
> But expandos are usually added to HTMLElement and other builtin elements,
> right?
Depends, might be on instances too.
> What we're talking about here is adding properties and methods on a custom
> element, which is a subclass of HTMLElem
On May 12, 2014, at 2:00 AM, Anne van Kesteren wrote:
> On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa wrote:
>> On the other hand, if the same element had exposed contentEditable property,
>> then UA's native contentEditable property would simply be overridden since
>> it would appear higher
On Mon, May 12, 2014 at 11:24 AM, Simon Pieters wrote:
> So when we research if it's safe to add a new global attribute, it's not
> enough to measure how often such an attribute is used in the wild. We need
> to research bare names in event handlers also.
This we can thankfully mitigate in the fu
On Mon, 12 May 2014 11:00:20 +0200, Anne van Kesteren
wrote:
On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa wrote:
On the other hand, if the same element had exposed contentEditable
property, then UA's native contentEditable property would simply be
overridden since it would appear higher
On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa wrote:
> On the other hand, if the same element had exposed contentEditable property,
> then UA's native contentEditable property would simply be overridden since it
> would appear higher up in the prototype chain. It's true that this custom
> elem
> On May 9, 2014, at 3:22 AM, Anne van Kesteren wrote:
>
>> On Thu, May 8, 2014 at 6:49 PM, Brian Kardell wrote:
>> What do the parsing rules say about what an attr may begin with? Is it
>> plausible to just leading underscore or leading dash them as in CSS so that
>> all that's really necessar
On Thu, May 8, 2014 at 6:49 PM, Brian Kardell wrote:
> What do the parsing rules say about what an attr may begin with? Is it
> plausible to just leading underscore or leading dash them as in CSS so that
> all that's really necessary is for HTML to avoid using those natively (not
> hard, cause, wh
On Thu, May 8, 2014 at 5:37 AM, Anne van Kesteren wrote:
> On Thu, May 8, 2014 at 12:53 AM, Ryosuke Niwa wrote:
> > The answer to that question, IMO, is no. It's not safe to use custom
> > attributes without 'data-' if one wanted to write a forward compatible
> HTML
> > document.
>
> Note that
On Thu, 8 May 2014, Bruce Lawson wrote:
> On 7 May 2014 20:03, Ian Hickson wrote:
> >
> > Requiring a dash is pretty ugly. I would allow any attribute, and
> > we'll just have to be careful when introducing new global ones.
>
> I think the ship HMS Ugly has already sailed, given a dash is compul
On Thu, May 8, 2014 at 12:53 AM, Ryosuke Niwa wrote:
> The answer to that question, IMO, is no. It's not safe to use custom
> attributes without 'data-' if one wanted to write a forward compatible HTML
> document.
Note that the question is scoped to custom elements, not elements in general.
It
On 7 May 2014 20:03, Ian Hickson wrote:
>
> Requiring a dash is pretty ugly. I would allow any attribute, and we'll
> just have to be careful when introducing new global ones.
I think the ship HMS Ugly has already sailed, given a dash is
compulsory for the names of custom elements. Also, requiri
On May 7, 2014, at 4:30 PM, Glenn Maynard wrote:
> On Wed, May 7, 2014 at 5:07 PM, Ryosuke Niwa wrote:
> There is a difference in people not caring about forward compatibility and
> polluting the global namespace, and not providing a mechanism to do it right
> in the first place.
>
> You'll a
On Wed, May 7, 2014 at 5:07 PM, Ryosuke Niwa wrote:
> There is a difference in people not caring about forward compatibility and
> polluting the global namespace, and not providing a mechanism to do it
> right in the first place.
>
You'll always need to be able to declare attributes that the bro
There is a difference in people not caring about forward compatibility and
polluting the global namespace, and not providing a mechanism to do it right in
the first place.
If we're encouraging authors to define their own attributes, then we should
provide a mechanism or a guideline to do so in
On Wed, 7 May 2014, Ryosuke Niwa wrote:
>
> How are you going to quantify the risk of adding a new global attribute
> in the future?
Same we we do today. Look to see how many pages use the attribute, find a
name that's not used much, and then try to deploy it and see what breaks.
> I don't wa
Le 07/05/2014 21:36, Ryosuke Niwa a écrit :
On May 7, 2014, at 12:03 PM, Ian Hickson wrote:
On Wed, 7 May 2014, Anne van Kesteren wrote:
On Tue, May 6, 2014 at 7:19 PM, Wilson Page wrote:
I'm unsure whether or not it is safe to use custom attributes without
the 'data-', I've heard mixed opi
On May 7, 2014, at 12:03 PM, Ian Hickson wrote:
> On Wed, 7 May 2014, Anne van Kesteren wrote:
>> On Tue, May 6, 2014 at 7:19 PM, Wilson Page wrote:
>>> I'm unsure whether or not it is safe to use custom attributes without
>>> the 'data-', I've heard mixed opinions. How do we know that chosen
On Wed, 7 May 2014, Anne van Kesteren wrote:
> On Tue, May 6, 2014 at 7:19 PM, Wilson Page wrote:
> > I'm unsure whether or not it is safe to use custom attributes without
> > the 'data-', I've heard mixed opinions. How do we know that chosen
> > attributes won't someday be global attributes?
>
On Tue, May 6, 2014 at 7:19 PM, Wilson Page wrote:
> I'm unsure whether or not it is safe to use custom attributes without the
> 'data-', I've heard mixed opinions. How do we know that chosen attributes
> won't someday be global attributes?
Yeah, we should figure something out here. From one pers
I'm unsure whether or not it is safe to use custom attributes without the
'data-', I've heard mixed opinions. How do we know that chosen attributes
won't someday be global attributes?
28 matches
Mail list logo
