On Feb 4, 2015, at 4:56 AM, Olli Pettay o...@pettay.fi wrote:
On 02/03/2015 04:22 PM, Brian Kardell wrote:
On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi
mailto:o...@pettay.fi wrote:
On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
Brian recently posted what
On Feb 4, 2015, at 7:59 AM, Domenic Denicola d...@domenic.me wrote:
In IRC Anne and I were briefly discussing how type= is the is= of Web
Applications 1.0. That is, input type=date is similar to img is=x-gif
or similar---it has a reasonable fallback behavior, but in reality it is a
Yeah, I had noted in that post that wrapping a native element with a custom
element was an option - only drawback is that the markup isn't as terse (which
is generally advertised as one of the selling points of Custom Elements). But
that doesn't seem like a deal breaker to me, if subclassing
On 4 February 2015 at 16:51, Ryosuke Niwa rn...@apple.com wrote:
my-custom-formatterinput/my-custom-formatter
I think if this worked. i.e. hid the styling and allowed styling over top,
while allowing access to the input functionality would be a good solution
for the many many instances of
See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html
first.
On Feb 4, 2015, at 6:43 AM, Chris Bateman chrisb...@gmail.com wrote:
Assuming a situation where a native element – with custom
I just joined the group today, so thought I should introduce myself. My name is
Ted Dinklocker and I work at Microsoft on the Internet Explorer Platform team.
I am excited to work with all of you to help drive web interoperability and
capability! A short bio:
I have worked in technology and
On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote:
On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote:
On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote:
On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com
wrote:
So a web page author would write
x-slider min=-100 ... etc.
and then the custom element would sprout an input type=range ...etc
with the attribute values copied across? Then the web page author knows
nothing about the input element, so if they want to programmatically the
value of the custom
On Feb 4, 2015, at 11:26 AM, Alice Boxhall aboxh...@google.com wrote:
So a web page author would write
x-slider min=-100 ... etc.
and then the custom element would sprout an input type=range ...etc with
the attribute values copied across?
No. The page author would write x-sliderinput
On Feb 4, 2015, at 10:54 AM, Alice Boxhall aboxh...@google.com wrote:
On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com
mailto:rn...@apple.com wrote:
On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com
mailto:bkard...@gmail.com wrote:
On Wed, Feb 4, 2015 at
On Feb 4, 2015, at 11:11 AM, Chris Bateman chrisb...@gmail.com wrote:
Ugh, I forgot about that. Without subclassing - terseness is a very minor
drawback, but remapping the interface is a big pain.
Could you give us a concrete use case in which remapping the interface is
necessary or
On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com wrote:
Yeah, I had noted in that post that wrapping a native element with a
custom element was an option - only drawback is that the markup isn't as
terse (which is generally advertised as one of the selling points of Custom
On Feb 4, 2015, at 9:05 AM, Steve Faulkner faulkner.st...@gmail.com wrote:
On 4 February 2015 at 16:51, Ryosuke Niwa rn...@apple.com
mailto:rn...@apple.com wrote:
my-custom-formatterinput/my-custom-formatter
I think if this worked. i.e. hid the styling and allowed styling over top,
On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com wrote:
On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote:
On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote:
On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote:
On
On 4 February 2015 at 19:05, Alice Boxhall aboxh...@google.com wrote:
So then how do we treat it as fallback content i.e. un-rendered, while
allowing it to be accessible to to the AT layer?
I suggest as in the working canvas example i provided, it not only be
exposed AT but also to keyboard
On Feb 4, 2015, at 11:05 AM, Alice Boxhall aboxh...@google.com wrote:
On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com
mailto:bkard...@gmail.com wrote:
On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com
mailto:aboxh...@google.com wrote:
On Wed, Feb 4,
Ugh, I forgot about that. Without subclassing - terseness is a very minor
drawback, but remapping the interface is a big pain.
On Wed, Feb 4, 2015 at 1:01 PM, Brian Kardell bkard...@gmail.com wrote:
On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote:
On Wed, Feb 4, 2015
I know I'm rather late to the party, but I've been doing a lot of
reading lately about web components and related technologies, and the
one thing that confounds me is the fact that web components appear not
to have any real namespacing.
Can someone explain why this is so, and what the
On Wed, Feb 4, 2015 at 2:31 PM, Glen glen...@gmail.com wrote:
I know I'm rather late to the party, but I've been doing a lot of reading
lately about web components and related technologies, and the one thing
that confounds me is the fact that web components appear not to have any
real
It doesn't really matter whether or not it's based on (or at least
resembles) XML, as long as there is some way to specify (and redefine)
the prefix of custom elements.
G.
On 2015/02/04 23:39, Glenn Adams wrote:
On Wed, Feb 4, 2015 at 2:31 PM, Glen glen...@gmail.com
Assuming a situation where a native element – with custom functionality –
is dynamically injected into the page, the basic options I can think of are:
- input is=my-custom-formatter
- input class=my-custom-formatter and a page-level listener
- input class=my-custom-formatter and call a
On Wed, Feb 4, 2015 at 3:43 PM, Chris Bateman chrisb...@gmail.com wrote:
An better example of both A and B (than my previous hypothetical) might be
GitHub's time is=relative-time extension:
https://github.com/github/time-elements/.
FWIW, I do want subclassing of builtins to work. Maybe not
I hope others can address the question of why custom element callbacks are
useful, and meet the bar of being a feature we should add to the web platform
(with all the UA-coordination that requires). I just wanted to interject into
this input discussion.
In IRC Anne and I were briefly
On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote:
Why do we need shadow DOM (or something similar) at all if we expose it
easily to the outside world.
One could even now just require that elements in components in a web page
have class=component, and then
.component could be
On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote:
Why do we need shadow DOM (or something similar) at all if we expose it
easily to the outside world.
One could even now just require that elements in
On Thu, Feb 5, 2015 at 10:56 AM, Ryosuke Niwa rn...@apple.com wrote:
On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote:
Why do we need shadow DOM (or something similar) at all if we expose it
easily to the
On Thu, Feb 5, 2015 at 11:03 AM, Olli Pettay o...@pettay.fi wrote:
On 02/05/2015 01:20 AM, Tab Atkins Jr. wrote:
You don't need strong isolation primitives to do a lot of good.
Simple composition helpers lift an *enormous* weight off the shoulders
of web devs, and make whole classes of bugs
On 02/05/2015 01:20 AM, Tab Atkins Jr. wrote:
You don't need strong isolation primitives to do a lot of good.
Simple composition helpers lift an *enormous* weight off the shoulders
of web devs, and make whole classes of bugs obsolete. Shadow DOM is
precisely that composition helper right now.
On Wed, Feb 4, 2015 at 3:56 PM, Ryosuke Niwa rn...@apple.com wrote:
On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote:
Why do we need shadow DOM (or something similar) at all if we expose it
easily
Glen -
Glenn has the answer.
So we're going to come up with yet-another-registry rather than use one
that already exists and guarantees (at least as far can be guaranteed)
uniqueness: DNS.
The ramifications of not making HTML5 be XHTML5 will be with us for a very
long time indeed.
Cheers,
-
Can either of you provide an example in layman's terms?
I don't quite understand what this will look like.
G.
On 2015/02/05 00:29, William Edney wrote:
Glen -
Glenn has the answer.
So we're going to come up with yet-another-registry rather than use
one that already exists and guarantees
On Thu, Feb 5, 2015 at 8:31 AM, Glen glen...@gmail.com wrote:
I know I'm rather late to the party, but I've been doing a lot of reading
lately about web components and related technologies, and the one thing that
confounds me is the fact that web components appear not to have any real
On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle kurt.ca...@gmail.com wrote:
I predict that sometime around 2025, we will end up redefining namespaces
because the number of jQuery-like components have ballooned into the
millions, the web has descended once again into a sea of interoperability,
and
I predict that sometime around 2025, we will end up redefining namespaces
because the number of jQuery-like components have ballooned into the
millions, the web has descended once again into a sea of interoperability,
and registries will, once again, have proven to be a bottleneck, as they
have
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965
Bug ID: 27965
Summary: [Shadow]: Shadow host with tabindex=-1, all descendent
tree should be ignored for tab navigation
Product: WebAppsWG
Version: unspecified
Hardware:
On 02/03/2015 07:24 PM, Dimitri Glazkov wrote:
Not trying to barge in, just sprinkling data...
On Tue, Feb 3, 2015 at 6:22 AM, Brian Kardell bkard...@gmail.com
mailto:bkard...@gmail.com wrote:
On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi
mailto:o...@pettay.fi wrote:
On Wed, Feb 4, 2015 at 8:37 AM, Tobie Langel tobie.lan...@gmail.com wrote:
On Wed, Feb 4, 2015 at 3:35 AM, Michael[tm] Smith m...@w3.org wrote:
Arthur Barstow art.bars...@gmail.com, 2015-02-02 08:47 -0500:
Archived-At: http://www.w3.org/mid/54cf7fe0.6090...@gmail.com
On 2/2/15 7:14 AM,
On 02/03/2015 04:22 PM, Brian Kardell wrote:
On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi
mailto:o...@pettay.fi wrote:
On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
Brian recently posted what looks like an excellent framing of the
composition problem:
On Wed, Feb 4, 2015 at 7:56 AM, Olli Pettay o...@pettay.fi wrote:
On 02/03/2015 04:22 PM, Brian Kardell wrote:
On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi mailto:
o...@pettay.fi wrote:
On 02/02/2015 09:22 PM, Dimitri Glazkov wrote:
Brian recently posted what
On Wed, Feb 4, 2015 at 11:36 PM, Olli Pettay o...@pettay.fi wrote:
Why should even !important work if the component wants to use its own
colors?
Because that's how !important usually works. If the author has
progressed to the point of doing !important, we should assume that
they know what
Glad to see this. I was 'checking in' on the professional practicalities of
custom elements earlier this week, and was pretty bummed when I couldn't
use XHTML5 namespaces for my employer's organization.
I build widgets all day. They run in inhospitable that websites I'm not in
control of. They
41 matches
Mail list logo
