On 24 Jun 2010, at 14:11, Benjamin M. Schwartz wrote:
>>> Why would it simplify parsing?
>> It greatly simplifies parsing when you just want to extract entire
>> tags, without immediately parsing the attributes.
>If you mean "parsing" with regular expressions, then I think that's a bad
practic
I disagree, there are so many other things you need to take account of if
you were (for example) getting all the text out of an HTML document. Text
and markup in comment nodes would just through a spanner in the works for
starters.
It all boils down to the fact that the only thing disallowing ">"
Hi, WHATWG folks-
As you are probably aware, some differences have arisen between the W3C
draft of the HTML5 spec and the larger WHATWG version. In my opinion,
the specific technical details of any given feature (which, let's be
fair, are often more-or-less arbitrary) is of lesser importance
On 2010-06-25 11:46, Skrol29 wrote:
A agree disallowing ">" chars in attributes greatly simplifies parsing. Not
only with regular expressions, but any parsing.
If ">" are allowed, it means that in order to found the end of the element
you do have to read all attributes before. This is very costy.
> A agree disallowing ">" chars in attributes greatly simplifies parsing. Not
> only with regular expressions, but any parsing.
> If ">" are allowed, it means that in order to found the end of the element
> you do have to read all attributes before. This is very costy.
You just need two extra stat
On Fri, 2010-06-25 at 13:28 +0100, Kornel Lesinski wrote:
> > A agree disallowing ">" chars in attributes greatly simplifies parsing. Not
> > only with regular expressions, but any parsing.
> > If ">" are allowed, it means that in order to found the end of the element
> > you do have to read all a
On Jun 25, 2010, at 5:13 AM, Doug Schepers wrote:
> There are a few possible ways to handle this:
> 1) W3C could match the WHATWG version in all details, with all decisions made
> by WHATWG
> 2) WHATWG could match the W3C version in all details, with all decisions made
> by W3C
> 3) WHATWG and W
On Thu, Jun 24, 2010 at 2:34 PM, Benjamin M. Schwartz
wrote:
> [...]
> HTML5 is about making a spec that matches common practice, right? In
> practice, no one puts ">" in attribute values.
The data disagrees: http://philip.html5.org/data/gt-in-attribute.txt
--
Philip Taylor
exc...@gmail.com
How is that productive? I realize that it's meant as a joke but it does nothing
but add to the impression that some in the WHATWG community just don't care
about civility, respect, and cooperation.
The best thing to counteract that impression is to prove it wrong.
On Jun 25, 2010, at 8:51 AM, P
-Message d'origine-
De : Lachln Hunt [mailto:lachlan.h...@lachy.id.au]
Envoyé : vendredi 25 juin 2010 14:18
À : Skrol29
Cc : 'WHAT Working Group'; b...@alum.mit.edu
Objet : Re: [whatwg] Allowing ">" in attribute values
On 2010-06-25 11:46, Skrol29 wrote:
>> A agree disallowing ">" chars i
Appreciate the informations on what's currently hurting the specs...
On Fri, Jun 25, 2010 at 12:13 PM, Doug Schepers wrote:
> Hi, WHATWG folks-
>
> As you are probably aware, some differences have arisen between the W3C
> draft of the HTML5 spec and the larger WHATWG version. In my opinion, the
On 25.06.2010 15:52, Skrol29 wrote:
...
Allowing ">" in attributes is a small gift of tolerance for webmasters, but
implies major complications for the industry.
Disallowing ">" falls within the purpose of simplifying the grammar, like when
XHTML disallowed the uppercase for element and attrib
On 6/25/10 9:52 AM, Skrol29 wrote:
In another hand, in the industry the tolerance to the spec is often very low in
order build simple, fast and robust processes. They are also many parsing
purposes that care about some elements and don't care about others.
As I see it, there are two possibili
On Fri, Jun 25, 2010 at 3:13 AM, Doug Schepers wrote:
> Hi, WHATWG folks-
>
> As you are probably aware, some differences have arisen between the W3C
> draft of the HTML5 spec and the larger WHATWG version. In my opinion, the
> specific technical details of any given feature (which, let's be fair
On 25.06.2010 18:11, Tab Atkins Jr. wrote:
...
Alternately, we could continue work solely in the HTMLWG. This would
not be possible unless we change the way the HTMLWG works somewhat,
though. There's a *reason* that almost no technical discussion
happens within the HTMLWG. If we were to pursue
On Fri, Jun 25, 2010 at 9:23 AM, Julian Reschke wrote:
> On 25.06.2010 18:11, Tab Atkins Jr. wrote:
>>
>> ...
>> Alternately, we could continue work solely in the HTMLWG. This would
>> not be possible unless we change the way the HTMLWG works somewhat,
>> though. There's a *reason* that almost n
On Fri, Jun 25, 2010 at 9:23 AM, Julian Reschke wrote:
> On 25.06.2010 18:11, Tab Atkins Jr. wrote:
>> ...
>> Alternately, we could continue work solely in the HTMLWG. This would
>> not be possible unless we change the way the HTMLWG works somewhat,
>> though. There's a *reason* that almost no t
On Fri, 25 Jun 2010 06:13:13 -0400, Doug Schepers wrote:
Hi, WHATWG folks-
As you are probably aware, some differences have arisen between the W3C
draft of the HTML5 spec and the larger WHATWG version. In my opinion,
the specific technical details of any given feature (which, let's be
f
On 25.06.2010 20:33, Michael A. Puls II wrote:
...
I do follow public-html, but my message list is full of a bunch of
messages with subjects like "isssue N" or "change proposal n" or "bug n
- part of the subject ...", which don't make any sense until I drift off
to the bts and have disconnected d
I would like to encourage peopel participating in this thread to focus
exclusively on coordination with the W3C. In particular, this is not the
right forum to discuss the W3C HTML WG public-html mailing list, the W3C
HTML WG's decision policies, or other W3C matters. We don't have the
authorit
On 06/25/2010 11:50 AM, Boris Zbarsky wrote:
> It seems like what you want here is for browsers to parse as they do
> now, but a particular subset of browser-accepted syntax to be enshrined
> so that when defining your restrictions over content you control you can
> just say "follow the spec" inste
On Fri, Jun 25, 2010 at 3:01 PM, Ian Hickson wrote:
>
>>
>> Maybe the answer is to have a spokesperson or liaison role, someone
>> respected in the WHATWG community with a reputation for reasonable
>> neutrality? Both Hixie and Maciej have conflicts of interest, as editor
>> and W3C co-chair resp
One advantage is almost the same as your footnote: JavaScript source is
permitted in the values of many attributes, and can certainly contain the >
operator.
On Jun 25, 2010 12:34 PM, "Benjamin M. Schwartz"
wrote:
> On 06/25/2010 11:50 AM, Boris Zbarsky wrote:
>> It seems like what you want here
On Fri, Jun 25, 2010 at 4:03 PM, Sam Ruby wrote:
>
> Yet, when you made the change, you did it in a way that made the
> WHATWG version not a proper superset.
On closer reading, it turns out that I was incorrect here. It still,
however, remains a divergence, it still is mis-characterized, and I a
On Fri, 25 Jun 2010, Sam Ruby wrote:
>
> We recently had a change proposal made by Lachlan:
> http://lists.w3.org/Archives/Public/public-html/2010Apr/1107.html
> Absolutely nobody in the W3C WG indicated any issues with this proposal:
> http://lists.w3.org/Archives/Public/public-html/2010Jun/0562.
On Thu, Jun 24, 2010 at 8:55 PM, Ashley Sheridan
wrote:
> I think it's quite a fringe case. What about things that are more used:
>
> * type=number - a browser could aid input with some sort of spinner
type=number has been in the spec for years.
On Thu, Jun 24, 2010 at 5:55 PM, Ashley Sheridan
wrote:
> I think it's quite a fringe case. What about things that are more used:
>
> type=number - a browser could aid input with some sort of spinner
> type=price - a browser could use the locale to select a monetary format, or
> at least display
On Fri, Jun 25, 2010 at 9:11 AM, Tab Atkins Jr. wrote:
> The WHATWG has a steering council made up of browser developers.
> Officially, they can override Ian's decisions or make him step down as
> editor. They've never had to exercise this power yet, though.
Could you elaborate on this? That *a
On Fri, 2010-06-25 at 17:09 -0400, Aryeh Gregor wrote:
> On Thu, Jun 24, 2010 at 8:55 PM, Ashley Sheridan
> wrote:
> > I think it's quite a fringe case. What about things that are more used:
> >
> > * type=number - a browser could aid input with some sort of spinner
>
> type=number has been in t
On Fri, Jun 25, 2010 at 1:51 PM, Ian Hickson wrote:
> I value technical merit even higher than convergence.
How is technical merit assessed? Removing Theora from the
specification, for example, seems like it was for political rather
than technical reasons, if I understand how you use the terms.
On Fri, Jun 25, 2010 at 2:45 PM, Ashley Sheridan
wrote:
>
> On Fri, 2010-06-25 at 17:09 -0400, Aryeh Gregor wrote:
> > type=number has been in the spec for years.
>
> Do you have a link to this to verify?
http://dev.w3.org/html5/markup/input.number.html is the fourth hit for
"type=number" in Goog
On Fri, Jun 25, 2010 at 2:45 PM, Mike Shaver wrote:
> On Fri, Jun 25, 2010 at 9:11 AM, Tab Atkins Jr. wrote:
>> The WHATWG has a steering council made up of browser developers.
>> Officially, they can override Ian's decisions or make him step down as
>> editor. They've never had to exercise this
On Fri, Jun 25, 2010 at 3:00 PM, Tab Atkins Jr. wrote:
> Bottom of the charter: http://www.whatwg.org/charter
>
> I believe the decision process is knife fight to first blood.
"Editors should reflect the consensus opinion of the working group
when writing their specifications, but it is the docum
On Fri, Jun 25, 2010 at 2:48 PM, Mike Shaver wrote:
> On Fri, Jun 25, 2010 at 1:51 PM, Ian Hickson wrote:
>> I value technical merit even higher than convergence.
>
> How is technical merit assessed? Removing Theora from the
> specification, for example, seems like it was for political rather
>
On Fri, Jun 25, 2010 at 3:06 PM, Mike Shaver wrote:
> On Fri, Jun 25, 2010 at 3:00 PM, Tab Atkins Jr. wrote:
>> Bottom of the charter: http://www.whatwg.org/charter
>>
>> I believe the decision process is knife fight to first blood.
>
> "Editors should reflect the consensus opinion of the working
On Thu, Jun 24, 2010 at 1:45 PM, Jeremy Keith wrote:
> Michelango wrote:
>>...
>> 3. Maps data are often non-free and non-open, reliable maps data are
>> always non-free and non-open.
>
> The second clause of point 3 is demonstrably false. Said demonstration is
> http://www.openstreetmap.org/ whi
On Fri, Jun 25, 2010 at 3:07 PM, Tab Atkins Jr. wrote:
>> How
>> can one learn of the technical motivations of decisions such as the
>> change to require ImageData for Canvas,
>
> On the WHATWG wiki a Rationale page is being assembled by a volunteer
> (don't know their name, but they go by 'variab
On Fri, Jun 25, 2010 at 3:15 PM, Mike Shaver wrote:
> On Fri, Jun 25, 2010 at 3:07 PM, Tab Atkins Jr. wrote:
>>> How
>>> can one learn of the technical motivations of decisions such as the
>>> change to require ImageData for Canvas,
>>
>> On the WHATWG wiki a Rationale page is being assembled by
On Fri, 25 Jun 2010, Mike Shaver wrote:
> On Fri, Jun 25, 2010 at 1:51 PM, Ian Hickson wrote:
> > I value technical merit even higher than convergence.
>
> How is technical merit assessed?
I read all the e-mails (and other feedback) sent on a topic, and try to
take everything into account and d
On Fri, Jun 25, 2010 at 3:09 PM, Tab Atkins Jr. wrote:
> I wasn't precise in my language - don't read too much into my exact wording.
No, certainly; I'm much more interested in the spirit here than the
wording, since it doesn't match my experience or understanding. I'll
take on my education burd
On Fri, Jun 25, 2010 at 6:13 AM, Doug Schepers wrote:
> As you are probably aware, some differences have arisen between the W3C
> draft of the HTML5 spec and the larger WHATWG version. In my opinion, the
> specific technical details of any given feature (which, let's be fair, are
> often more-or-
On Fri, Jun 25, 2010 at 3:01 PM, Ian Hickson wrote:
>
> While I agree that it is helpful for us to cooperate, I should point out
> that the WHATWG was never formally approached by the W3C about this
With whom (and where?) would such a "formal" discussion take place?
I would prefer that such a di
On Fri, Jun 25, 2010 at 3:30 PM, Aryeh Gregor wrote:
> I'm pretty sure they won't be. Any significant implementer has always
> had veto power over the spec.
I fear that simply refusing to implement is indeed the WHATWG's
equivalent of how Tab described FO-threats in the W3C environment: a
much m
On Fri, 25 Jun 2010, Sam Ruby wrote:
> On Fri, Jun 25, 2010 at 3:01 PM, Ian Hickson wrote:
> >
> > While I agree that it is helpful for us to cooperate, I should point out
> > that the WHATWG was never formally approached by the W3C about this
>
> With whom (and where?) would such a "formal" disc
On Fri, Jun 25, 2010 at 4:00 PM, Mike Shaver wrote:
> On Fri, Jun 25, 2010 at 3:30 PM, Aryeh Gregor
> wrote:
>> I'm pretty sure they won't be. Any significant implementer has always
>> had veto power over the spec.
>
> I fear that simply refusing to implement is indeed the WHATWG's
> equivalent
On Fri, 2010-06-25 at 16:11 -0700, Tab Atkins Jr. wrote:
> On Fri, Jun 25, 2010 at 4:00 PM, Mike Shaver wrote:
> > On Fri, Jun 25, 2010 at 3:30 PM, Aryeh Gregor
> > wrote:
> >> I'm pretty sure they won't be. Any significant implementer has always
> >> had veto power over the spec.
> >
> > I fe
On Jun 25, 2010, at 3:17 PM, Mike Shaver wrote:
> On Fri, Jun 25, 2010 at 3:09 PM, Tab Atkins Jr. wrote:
>> I wasn't precise in my language - don't read too much into my exact wording.
>
> No, certainly; I'm much more interested in the spirit here than the
> wording, since it doesn't match my e
On Fri, Jun 25, 2010 at 7:02 PM, Ian Hickson wrote:
> On Fri, 25 Jun 2010, Sam Ruby wrote:
>> On Fri, Jun 25, 2010 at 3:01 PM, Ian Hickson wrote:
>> >
>> > While I agree that it is helpful for us to cooperate, I should point out
>> > that the WHATWG was never formally approached by the W3C about
On Sat, Jun 26, 2010 at 11:00 AM, Mike Shaver wrote:
> That is not my recollection of what happened with offline, for what
> it's worth. Mozilla and Google had a relatively small set of
> deviations between approaches (ours developed on the whatwg list and
> Google's developed behind closed doors
On Fri, Jun 25, 2010 at 6:50 PM, Robert O'Callahan wrote:
> Who from Mozilla objected? I didn't object, because I thought Ian's approach
> (manifests) was better than ours (JAR files). And I thought ours was quite
> different from Gears' (which used manifests, IIRC).
There were two revision perio
50 matches
Mail list logo
