On Thu, 2010-06-24 at 19:30 -0400, Eitan Adler wrote:
> >
> > Seeing your 2c and raising you a "citation needed." ;-)
> >
> > But to the point at hand
> >
> > Would the @pattern attribute cover the use case of lat/long inputs? (albeit
> > without a nice UI)
>
> Possibly. I personally think
>
> Seeing your 2c and raising you a "citation needed." ;-)
>
> But to the point at hand
>
> Would the @pattern attribute cover the use case of lat/long inputs? (albeit
> without a nice UI)
Possibly. I personally think that the UI is worth adding it to the spec.
--
Eitan Adler
On Thu, Jun 24, 2010 at 9:34 AM, Benjamin M. Schwartz
wrote:
> HTML5 is about making a spec that matches common practice, right? In
> practice, no one puts ">" in attribute values.
HTML5 matches common practice when necessary to ensure
interoperability. That doesn't apply to authoring requireme
> Date: Thu, 24 Jun 2010 20:08:50 +0400
> From: Nikita Vasilyev
> The current version of spec
> http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#contenteditable
> does not define any way to make an element within contentEditable
> undeletable. I propose "undeletable" attr
Michelango wrote:
> 1. Maps are heavy to get, this means UA should heavily cache and/or it
> should own whole maps data (huge!)
> 2. If 1) didn't exist because UA can, for instance, get maps data in a
> blink of an eye: whose data are we gonna use?
> 3. Maps data are often non-free and non-open, re
It would be nice to know more details on how you are thinking to use this
and why this is very useful for code editors. If I select all my code and
hit Delete, don't I want to remove all the code, together with highlighting?
On Thu, Jun 24, 2010 at 9:08 AM, Nikita Vasilyev wrote:
> The current v
On Wed, Jun 23, 2010 at 6:35 PM, Adam Barth wrote:
> On Wed, Jun 23, 2010 at 6:05 PM, Ben Lerner wrote:
>> Additionally, the sandboxing flags seem to be more a feature of the
>> element than of the browsing context, because they depend on the value of
>> the ’s sandbox attribute. Can these flag
"Benjamin M. Schwartz" schrieb am Thu, 24
Jun 2010 11:20:10 -0400:
> Worldwide, regarding HTML, I'm sure there is 100 times more regular
> expression processing code than full-on lexing code. Most code that
> processes HTML is embedded in scripts, doing some small
> special-purpose operation.
R
On Thu, 2010-06-24 at 09:01 -0700, Tab Atkins Jr. wrote:
> On Thu, Jun 24, 2010 at 8:20 AM, Benjamin M. Schwartz
> wrote:
> > On 06/24/2010 11:04 AM, Kornel Lesinski wrote:
> >> If you mean "parsing" with regular expressions, then I think that's a bad
> >> practice and shouldn't be encouraged.
>
The current version of spec
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#contenteditable
does not define any way to make an element within contentEditable
undeletable. I propose "undeletable" attribute:
element.undeletable = "true" | "false"
How should it work:
On Thu, Jun 24, 2010 at 8:20 AM, Benjamin M. Schwartz
wrote:
> On 06/24/2010 11:04 AM, Kornel Lesinski wrote:
>> If you mean "parsing" with regular expressions, then I think that's a bad
>> practice and shouldn't be encouraged.
>
> Worldwide, regarding HTML, I'm sure there is 100 times more regul
On 06/24/2010 11:04 AM, Kornel Lesinski wrote:
> If you mean "parsing" with regular expressions, then I think that's a bad
> practice and shouldn't be encouraged.
Worldwide, regarding HTML, I'm sure there is 100 times more regular
expression processing code than full-on lexing code. Most code t
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
practice a
On 24.06.2010 16:03, Marques Johansson wrote:
I would like to see a standardization of HTTP streaming, not
necessarily "adaptive streaming" - but that could also be useful.
The HTTP spec is vague or incomplete on behaviors related to partial requests.
...
If you think that there is a bug in th
On 24.06.2010 15:34, Benjamin M. Schwartz wrote:
On 06/24/2010 05:22 AM, Brett Zamir wrote:
I do not see any reference to this in the XHTML 1.0 specification (nor
XHTML 1.1), and in XML, section 2.4, it states only that it must be
escaped if part of the sequence "]]>" in "content", which I guess
I would like to see a standardization of HTTP streaming, not
necessarily "adaptive streaming" - but that could also be useful.
The HTTP spec is vague or incomplete on behaviors related to partial requests.
To implement a streaming audio / video site where the user can only
receive data if their a
On 06/24/2010 05:22 AM, Brett Zamir wrote:
> I do not see any reference to this in the XHTML 1.0 specification (nor
> XHTML 1.1), and in XML, section 2.4, it states only that it must be
> escaped if part of the sequence "]]>" in "content", which I guess means
> only element content. E4X also does n
On 06/24/2010 03:43 AM, Anne van Kesteren wrote:
> Why would it simplify parsing?
It greatly simplifies parsing when you just want to extract entire tags,
without immediately parsing the attributes.
> It's rather nice to allow it for the
> feature.
The srcdoc already needs to be escaped and un
On 24.06.2010 10:00, Henri Sivonen wrote:
"Benjamin M. Schwartz" wrote:
The HTML5 spec appears to allow ">" inside an attribute value. For
example, the following page (note the body tag) passes the
experimental
HTML5 validator at w3c.org:
I think ">" should be disallowed inside attribute
On 6/24/2010 10:13 AM, Benjamin M. Schwartz wrote:
The HTML5 spec appears to allow ">" inside an attribute value. For
example, the following page (note the body tag) passes the experimental
HTML5 validator at w3c.org:
I think ">" should be disallowed inside attribute values. It is
disallo
"Benjamin M. Schwartz" wrote:
> The HTML5 spec appears to allow ">" inside an attribute value. For
> example, the following page (note the body tag) passes the
> experimental
> HTML5 validator at w3c.org:
>
>
>
>
>
> I think ">" should be disallowed inside attribute values. It is
> disall
On Thu, 24 Jun 2010 04:13:56 +0200, Benjamin M. Schwartz
wrote:
The HTML5 spec appears to allow ">" inside an attribute value. For
example, the following page (note the body tag) passes the experimental
HTML5 validator at w3c.org:
I think ">" should be disallowed inside attribute values.
22 matches
Mail list logo
