> On Apr 2, 2015, at 1:16 PM, Brian Kardell wrote:
>
> Many of simple cases that I see that you could potentially do with
> your approach as described, at least my understanding of what I've
> seen so far, can in fact be done today with several frameworks
> declaratively.. There is competition i
Some years ago there were also Internet Explorer 6, proprietary tags,
frameset web pages and the project for DHTML. There also was the idea of
simple JS expressions to be evaluated in CSS. Why does anybody not propose
to restore {expression()}?
Never been a fan of the "new is good" motto, but sayin
Hi all:
I see some interesting things and a correc t approach of the MVC model
-- speaking in terms of theory -- in the original proposal of Bobby.
Let me tell you something funny:
* I do not see any unconvenient working with , as bones, because
for, as far as I remember, my firsts
You don't have to show any magnificent markup example with pages of
description.
You have to show authors how this framework WORKS in real life. With
comprehensive use cases.
This is a polyfill. As you can find for any other "HTML magic" you see
around.
CSS is a different case. Without proper tools
> On Apr 2, 2015, at 12:11 PM, Martin Janecke wrote:
>
> On 02.04.15 04:59, Bobby Mozumder wrote:
>
>> The best experience should be on by default, and you need a built-in MVC
>> framework in HTML for that to happen.
>
> That's something you take for granted, but other people don't. Apparentl
> On Apr 2, 2015, at 3:22 PM, Rimantas Liubertas wrote:
>
>>> There are fundamental problems with your proposal, namely:
>>> 1) it relies on some undefined magic
>>
>> I believe that’s called “programming”.
>
> So that poor fashion designer will have to learn to program after all…
The browse
> > There are fundamental problems with your proposal, namely:
> > 1) it relies on some undefined magic
>
> I believe that’s called “programming”.
So that poor fashion designer will have to learn to program after all…
> > 2) it changes HTML to something entirely different.
>
> To what? HTML
> On Apr 2, 2015, at 4:23 AM, Rimantas Liubertas wrote:
>
>> I gave a limited one-page idea for now, so design faults should be obvious.
>> This will take years, but right now it’s looking like there aren’t
>> fundamental problems with the proposal.
>
> There are fundamental problems with you
On 04/02/2015 04:08 AM, Andrea Rendine wrote:
Well, this means that we must also simplify CSS, don't you think
so? all that stuff about media queries, about animation and transitions,
pseudo-elements, pseudo-classes, how can poor Tumblr users learn
that?
Oh god yes, I like CSS selectors but
On Wed, Apr 1, 2015 at 10:59 PM, Bobby Mozumder wrote:
>
>> On Mar 31, 2015, at 12:43 PM, Joshua Cranmer wrote:
>>
>> On 3/30/2015 10:02 PM, Bobby Mozumder wrote:
>>> One thing I’m interested in is to see more technical discussions > around
>>> this idea. Like, very specific issues that show a
On 02.04.15 04:59, Bobby Mozumder wrote:
The best experience should be on by default, and you need a built-in MVC
framework in HTML for that to happen.
That's something you take for granted, but other people don't.
Apparently, people want to see the claim substantiated.
I understood that t
On 02/04/15 09:36, Simon Pieters wrote:
> I think we should not design a new API to test for features that should
> already be testable but aren't because of browser bugs. Many in that
> list are due to browser bugs. All points under "HTML5" are browser bugs
> AFAICT. Audio/video lists some incons
> On Apr 2, 2015, at 3:22 AM, Mat Carey wrote:
>
>> This will take years, but right now it’s looking like there aren’t
>> fundamental problems with the proposal
> My fundamental problem with this proposal is that it doesn’t blend well with
> the HTML we have - this group puts a lot of effort i
https://www.youtube.com/watch?v=ulNSlES1Fds
On Thu, Apr 2, 2015 at 1:08 PM, Andrea Rendine <
master.skywalker...@gmail.com> wrote:
> Bobby,
> stop talking about "comfort zone" and "scared programmers" and start acting
> like a person who considers anybody else worth discussing with, instead of
>
So let's take the Clipboard API as Example #2.
Given the current state of things, the abandoned/unreliable former
feature/command testing APIs I previously mentioned, and the fact that the
API is based around a long-standing concept (copy/cut/paste) that already
has overlapping attributes and even
Bobby,
stop talking about "comfort zone" and "scared programmers" and start acting
like a person who considers anybody else worth discussing with, instead of
a bunch of stupid people acting for their own interest.
What you propose is as complex and impractical as a JS framework is.
Moreover, an aut
Le 2 avr. 2015 à 17:36, Simon Pieters a écrit :
> On Wed, 01 Apr 2015 06:57:43 +0200, Kyle Simpson wrote:
>> There are features being added to the DOM/web platform, or at least under
>> consideration, that do not have reasonable feature tests obvious/practical
>> in their design.
>
> I think
On Wed, 01 Apr 2015 06:57:43 +0200, Kyle Simpson wrote:
There are features being added to the DOM/web platform, or at least
under consideration, that do not have reasonable feature tests
obvious/practical in their design. I consider this a problem, because
all features which authors (espec
> I gave a limited one-page idea for now, so design faults should be obvious.
> This will take years, but right now it’s looking like there aren’t
> fundamental problems with the proposal.
There are fundamental problems with your proposal, namely:
1) it relies on some undefined magic
2) it cha
Hi Bobby - I’m going to keep my response brief as I don’t want to get sucked
into this one too deep:
> all Tumblr kids pretty much know the basics of HTML
What you’ve proposed is not simple HTML, they won’t learn it.
> Javascript people are going to be happy with their existing selection of MVC
20 matches
Mail list logo
