On Tue, Feb 19, 2013 at 12:24 PM, Rafael Weinstein wrote:
> On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking wrote:
>>
>> On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren
>> wrote:
>> > On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov
>> > wrote:
>> >> We were thinking of adding innerHTML to D
My personal experience is different. We found that using img tags is not that
reliable. Especially in Firefox we recently saw some problems. Img tags in
general have the disadvantage that the amount of data that can be set is rather
limited. While this obviously should be kept as small as possib
Nope, you're 100% right, I saw *header *and thought HTML*Heading*Element
for some reason - so this seems like a valid concern. What are the
mitigation/solution options we can present to developers for this case?
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Tue,
Perhaps I'm making a mistake, but there is no specific prototype for the
native header element. 'header', 'footer', 'section', e.g., are all
HTMLElement, so all I can do is
FancyHeaderPrototype = Object.create(HTMLElement.prototype);
Afaict, the 'headerness' cannot be expressed this way.
On Tue
If someone wants to use custom elements in HTML then is the
following possible in principle?
Let's assume that I want to use Label element.
1. Parsing:
When parsing document containing this the parser
creates DOM element with the tagName "checkbox".
The element is created as an instance of clas
Wait a sec, perhaps I've missed something, but in your example you never
extend the actual native header element, was that on purpose? I was under
the impression you still needed to inherit from it in the prototype
creation/registration phase, is that not true?
On Feb 19, 2013 8:26 PM, "Scott Miles
Question: if I do
FancyHeaderPrototype = Object.create(HTMLElement.prototype);
document.register('fancy-header', {
prototype: FancyHeaderPrototype
...
In this case, I intend to extend "header". I expect my custom elements to
look like , but how does the system know what
localName to use? I beli
± From: Robin Berjon [mailto:ro...@w3.org]
± Sent: Tuesday, February 19, 2013 1:18 AM
±
± My recall is a bit rusty on that one, but I think that the situation was
± that:
±
± . WebApps is not chartered to publish this, so a CG was created.
±
± . But having the discussion on the CG list seemed li
Adding Blake and William, the Mozilla folks working on this. I
apologize for not thinking of you guys earlier :)
On Tue, Feb 19, 2013 at 7:01 PM, Scott Miles wrote:
> I think you captured it well, thank you for distillation.
>
> Perhaps one other COST of the localName issue is the question of
> d
I think you captured it well, thank you for distillation.
Perhaps one other COST of the localName issue is the question of
document.createElement.
document.createElement('x-button') creates , people
complain because the tag names do not match.
document.createElement('button').setAttribute('is', '
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20833
Joshua Bell changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18656
Eliot Graff changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18558
Eliot Graff changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Hi folks!
Since the very early ages of Web Components, one of the use cases was
implementing built-in HTML elements
(http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases#Built-in_HTML_Elements).
So, I spent a bit of time today trying to understand how our progress
with custom elements al
What is the harm in returning the same constructor that is being input for
this form of invocation? The output constructor is simply a pass-through of
the input constructor, right?
FOO_CONSTRUCTOR = document.register(‘x-foo’, {
constructor: FOO_CONSTRUCTOR
});
I guess this isn't a big deal thou
>> I'd be a much happier camper if I didn't have to think about handling
different return values.
I agree, and If it were up to me, there would be just one API for
document.register.
However, the argument given for dividing the API is that it is improper to
have a function return a value that is
On 02/19/2013 10:24 PM, Rafael Weinstein wrote:
On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking mailto:jo...@sicking.cc>> wrote:
On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren mailto:ann...@annevk.nl>> wrote:
> On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov mailto:dglaz...@google.
On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking wrote:
> On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren
> wrote:
> > On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov
> wrote:
> >> We were thinking of adding innerHTML to DocumentFragments anyway...
> right, Anne?
> >
> > Well I thought so, b
On 2/19/13 3:02 PM, Tab Atkins Jr. wrote:
For example, if you intend for the component to contain a
Oh, effects with components in particular.
Yeah, ignoring the rearrangement done by components for purposes of
counters makes sense to me.
-Boris
On Tue, Feb 19, 2013 at 11:49 AM, Boris Zbarsky wrote:
> On 2/19/13 2:43 PM, Tab Atkins Jr. wrote:
>> There's some layer-breaching intrinsic to this. You do have to
>> examine your styles to see if you generate a box.
>
> Well, your styles and the styles of all your ancestors in the flattened
> t
On 2/19/13 2:43 PM, Tab Atkins Jr. wrote:
There's some layer-breaching intrinsic to this. You do have to
examine your styles to see if you generate a box.
Well, your styles and the styles of all your ancestors in the flattened
tree, yes?
I wouldn't want it to rely on the box tree, though,
On Tue, Feb 19, 2013 at 11:38 AM, Boris Zbarsky wrote:
> On 2/19/13 2:20 PM, Elliott Sprehn wrote:
>> Currently in Webkit list item counting is done on the render tree, but
>> we are looking at making it use the DOM instead so that ordered lists
>> work properly in regions.
>
> Why wouldn't they w
On 2/19/13 2:20 PM, Elliott Sprehn wrote:
Currently in Webkit list item counting is done on the render tree, but
we are looking at making it use the DOM instead so that ordered lists
work properly in regions.
Why wouldn't they work properly even if done on the render tree?
Note that if you do
On 2/19/13 1:51 PM, Anne van Kesteren wrote:
Does that include cases though where the page did set a Content-Type
through setRequestHeader()?
That's a good question. I don't remember anymore; I'd have to go read
the relevant bugs.
Because technically what Firefox does
violates HTTP semanti
Currently in Webkit list item counting is done on the render tree, but we
are looking at making it use the DOM instead so that ordered lists work
properly in regions. This raises an interesting question about if they
should use the composed shadow tree, or the original tree.
ex.
inside
On 2013-02-19 19:51, Anne van Kesteren wrote:
On Tue, Feb 19, 2013 at 6:44 PM, Boris Zbarsky wrote:
Note that Firefox adds the charset even if it wasn't set by the page because
web developers were asking for it to aid server-side processing... The
alternative is that the server has no idea wha
On Tue, Feb 19, 2013 at 6:44 PM, Boris Zbarsky wrote:
> Note that Firefox adds the charset even if it wasn't set by the page because
> web developers were asking for it to aid server-side processing... The
> alternative is that the server has no idea what to do with the data. :(
Does that inclu
On 2/19/13 1:40 PM, Anne van Kesteren wrote:
On Tue, Feb 19, 2013 at 5:51 PM, David Bruant wrote:
My understanding of the spec is that the charset shouldn't be added,
because:
1) the Content-Type header is in author request header
2) the value is a valid MIME-type (tell me if I'm wrong on this)
On Tue, Feb 19, 2013 at 5:51 PM, David Bruant wrote:
> My understanding of the spec is that the charset shouldn't be added,
> because:
> 1) the Content-Type header is in author request header
> 2) the value is a valid MIME-type (tell me if I'm wrong on this)
> 3) it does not have a charset paramet
Hi,
Nicolas Chambrier (he's not registered to the list, please keep him in
the CC in your replies) and I came across that case recently:
1) create an XHR object (POST in case it matters)
2) set the "Content-Type" header explicitly (it changes, but we noticed
it with something like "application
cc John Neumann
On Tue, Feb 19, 2013 at 11:48 AM, Oliver Hunt wrote:
> JSON is deliberately minimal and deliberately unversioned.
>
> What are you expecting this working group to do? Also, given that JSON is
> essentially a subset of ECMAScript literal syntax, I'm unsure why this
> isn't being
JSON is deliberately minimal and deliberately unversioned.
What are you expecting this working group to do? Also, given that JSON is
essentially a subset of ECMAScript literal syntax, I'm unsure why this isn't
being handled by TC39
--Oliver
On Feb 18, 2013, at 4:19 PM, Bjoern Hoehrmann wrot
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17046
Anne changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
WebApps' last discussion about `group scope` and the HTML Editing spec
was September 2011 [1]. At that time, WebApps agreed the Editing CG may
use public-webapps since WebApps' charter then permitted WebApps to
directly take on APIs that were removed from the HTML5 spec.
Robin volunteered to h
On 02/19/2013 10:17 AM, Robin Berjon wrote:
On 19/02/2013 05:56 , Travis Leithead wrote:
Alex, work on Editing APIs was ongoing in the Community Group
(http://www.w3.org/community/editing/) though their draft is just under
a year old.
My recall is a bit rusty on that one, but I think that the
On 19/02/2013 05:56 , Travis Leithead wrote:
Alex, work on Editing APIs was ongoing in the Community Group
(http://www.w3.org/community/editing/) though their draft is just under
a year old.
My recall is a bit rusty on that one, but I think that the situation was
that:
• WebApps is not chart
± From: annevankeste...@gmail.com
± Sent: Monday, February 18, 2013 11:16 PM
±
± On Tue, Feb 19, 2013 at 4:14 AM, Alex Mogilevsky
wrote:
± > I am working on editing in IE, have issues of various scale that could
± > benefit from a discussion in standards environment. Short of creating
± > a new
37 matches
Mail list logo
