From dev-return-3355-archive-asf-public=cust-asf.ponee.io@royale.apache.org Mon Mar 12 11:29:29 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id B574718064D for ; Mon, 12 Mar 2018 11:29:28 +0100 (CET) Received: (qmail 73571 invoked by uid 500); 12 Mar 2018 10:29:27 -0000 Mailing-List: contact dev-help@royale.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@royale.apache.org Delivered-To: mailing list dev@royale.apache.org Received: (qmail 73559 invoked by uid 99); 12 Mar 2018 10:29:27 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Mar 2018 10:29:27 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 9922CC00CD for ; Mon, 12 Mar 2018 10:29:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.648 X-Spam-Level: X-Spam-Status: No, score=0.648 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KAM_INFOUSMEBIZ=0.75, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id nuZiJIEOHzaZ for ; Mon, 12 Mar 2018 10:29:24 +0000 (UTC) Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 59A275F216 for ; Mon, 12 Mar 2018 10:29:24 +0000 (UTC) Received: by mail-wr0-f171.google.com with SMTP id r66so7500989wrb.6 for ; Mon, 12 Mar 2018 03:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=d0UOCRcqO4cIu1hYot+RxfFy8RyxJBijbrHlT8hVnj0=; b=fR63YUtwxtNF4MYtx2xVlK9wmM6qXTHsl++A9SWdIqLRAgA2IILfU08nmCxvo7/DgU BGVJcemORhRRLlYnBSYUwH8w/IF3xFbXXkdbAHeFDRUl3wYPdK6z765jYuZfqW2uMNk+ Ge9tPkTH42oWLGWLoNcYoL106+EWfUlQxeI1DDiSBiNR4BHvqbPILIkwcDsY+cxhnMPD ZkP9gOuQhGFpan3P+jL1Bv/MVdMnknZKOF0BmxF949fRWBSAO+a7lqegjSEUdOaL6I7P ILDAZlc1PmY6/13VkXxuoQak6W08Doz26xpGhgrzP2iHFzzuyhmQJADP+cw136nZCdRq H1Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=d0UOCRcqO4cIu1hYot+RxfFy8RyxJBijbrHlT8hVnj0=; b=Pfr3HOwUezybM1dGm+XD61jc74GpTmdu3lahF0ib+BcC81vGqleFDNZzOzE9G28hpf zdCB6TTu6hTn3SMOw+GjKO3MY4dMVm553PlAl40DEuQAKKG1wiT6PToxd34ORsj4CF11 He/KaTQRD1hfTUlMGab7mwdILsutOJDi7iaeiW9HECGTRQgu1gs8NslD/rqLKYwLjc+F PAvvIpZduAeIFKyVs2pGp/5jcDryQVXC1+ipqYPKFEF4HFVtf1D2NFnqY4p4UZpydrwI O7+KvZUqdMYNRg57fhx9MjNS5lhX5Ssl1ifStMy9zHR5mVs+LSgUM5/oeKq9HbiYLGzX gG6w== X-Gm-Message-State: AElRT7FNi0PLnetLEwLETZMvWw8jHgeCxbWLtkYzWN7fjRx70FTh6X4M RsGwQhOSjS1J6q3LSC74INlfVWDu X-Google-Smtp-Source: AG47ELsXLyZvoSXtMk0P1Bi0wFLomhYtxOak4QOujqGBIjbobuvTCf7fW4XqTMjzzPQe2PR9CLlOVw== X-Received: by 10.223.182.2 with SMTP id f2mr5357668wre.117.1520850563738; Mon, 12 Mar 2018 03:29:23 -0700 (PDT) Received: from [10.0.0.14] ([82.166.23.15]) by smtp.gmail.com with ESMTPSA id i44sm7803928wri.23.2018.03.12.03.29.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 03:29:22 -0700 (PDT) From: Harbs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block" Date: Mon, 12 Mar 2018 12:29:20 +0200 References: <70D9864A-33E5-4792-8326-77D3A1B747D6@gmail.com> <38FC0831-89A4-4CA0-A9CE-DA65B603A292@gmail.com> To: dev@royale.apache.org In-Reply-To: Message-Id: <8FF73FED-3CAA-4C31-9281-5884B7B55BF1@gmail.com> X-Mailer: Apple Mail (2.3273) I also care about the HTML output, but in a different way than you (I = think). I care that it should be easy to debug and reason out why things = are happening. Can you explain why you care about inline CSS? I=E2=80=99m not getting = it. If find it much easier to understand inline CSS. It=E2=80=99s sometimes = difficult to figure out what sets specific inline styles, but it=E2=80=99s= also difficult sometimes to figure out what sets classes. Working = through complex CSS style sheets and figuring out which sheet is setting = what style and why is a *very* time consuming process. In my experience, = style sheets makes debugging more difficult and not easier. Harbs > On Mar 12, 2018, at 12:22 PM, Carlos Rovira = wrote: >=20 > Hi, >=20 > I see we have very different ways to how we see royale. In the end I = see > Royale like you, but I care about the output we get in HTML in = concrete, > since is different than the code we can produce in other outputs like = AS3 > (and maybe some day in Java, Swift,...). HTML is what is delivered to = the > final user, the rest not since are compiled to bytecode and are not as > inspectable as HTML. >=20 > anyway, I think is good to have different points of view but with care = so > the positions could co-exists. >=20 > thanks >=20 >=20 > 2018-03-12 10:55 GMT+01:00 Harbs : >=20 >>> the frameworks I'm watching are MDL, Semantic and Bootstrap (all top >>> frameworks) to see what they do in different cases and guide me to = find >> the >>> best way to implement the HTML Jewel should output in royale in = Royale. >> All >>> of this frameworks are only HTML/JS/CSS (not builds from other = code), >> but I >>> think that's not the point, since in the end both build front end >>> interfaces with controls and layouts >>=20 >> It=E2=80=99s very much the point. These are all frameworks which = attempt to enable >> a *document markup* (i.e. HTML) to be styled. Sure people use this = for web >> apps, but it=E2=80=99s an abuse of what HTML was originally designed = to be. >>=20 >> The way I see Royale is an *application framework* which simply uses = HTML >> and browsers as a *rendering engine*. Our goal isn=E2=80=99t and = *should not be* >> pretty HTML markup. That=E2=80=99s only important if you are *writing = HTML >> documents*. The strength of CSS is that it allows the styling to be >> divorced from the documentation and content. That is *not* an = important >> goal for application development. It *is* important for (a subset of) >> applications to be easily skinned, but CSS files should be a means = (if >> necessary) and *not* a goal. >>=20 >>> So are you telling me that our output is better than theirs? That = our way >>> of put somethings in the own html markup is better than theirs? I = don't >>> think so, since they do the same but with better results: better >> optimized >>> and less weight html code. >>=20 >> Yes. CSS lookups are inherently inefficient. =E2=80=9CPretty=E2=80=9D = HTML markup is *not* >> optimized. If CSS styling is not inlined, the browser must look = through >> (sometimes quite complex) lookup tables to figure out what the = styling >> should be. The fact that browsers can execute CSS lookups as quickly = as >> they do is quite amazing. >>=20 >>> In the other hand, you are telling me to write a bead to override or >>> correct something the framework is hardcoding? I suppose you are >> referring >>> to a bead that removes all styles hardcoded, so that doesn't strikes = out >> my >>> CSS styles... I think that's not the way to solve this. If I were = making >> an >>> App maybe that's could be the solution as a workaround, but we are >>> framework developers, not users. >>=20 >> I think that any properties in a theme which can only be specified = using >> CSS files should have any inline css zeroed out by a bead. I would = look for >> ways to have the values inlined though. Possibly the themes can be >> swappable beads which overwrite styles? Don=E2=80=99t know... >>=20 >>> I think that solution was good to start with, but now it demands to >>> refactor to something better. >>>=20 >>> Harbs, are we trying to make the best framework out there? I think = this >>> concrete point will make people reject us when they started to see = the >> html >>> we product all bloated with styles, when that's not necessary and = can be >> on >>> a "first level" CSS that be part of the lib code (not a theme) and = be >>> included always. I think that's the right solution and we'll get the = same >>> we have now but in the right insertion point. >>=20 >> I really don=E2=80=99t think that=E2=80=99s true. If you are talking = about people who >> *like* writing HTML, they=E2=80=99re not going to want to use Royale = anyway. To me >> a big part of the attraction of Royale is that I can avoid (for the = most >> part) writing HTML in my app. The attraction is MXML and ActionScript = files >> and avoiding complex HTML and CSS files. >>=20 >> Again: Default inline css can easily be overwritten (or zeroed out) = in >> beads for cases when it=E2=80=99s needed. I see no need for major = changes to the >> architecture. >>=20 >> My $0.02, >> Harbs >>=20 >>=20 >=20 >=20 > --=20 > Carlos Rovira > http://about.me/carlosrovira